[Oberon] string manipulation

[Chris Burrows]

>
>Thank, this makes things clearer. Now, since I'm a bit blocked 
>in low-level details, I would be glad to watch an 
>implementation of a string *type* (similar to those in most 
>Pascal variants, for instance) in any Oberon implementation.
>In fact, the issue is that even if I can build a string type 
>to manipulate strings, it is unusable in practice since no 
>builtin function/procedure can use it, eg:
>	Out.String(aText);
>I thus need an additional method to return the char sequence itself:
>	Out.String(aText.chars());
>But such a method cannot exist since it would have to return 
>an ARRAY OF CHAR. ;-) the impression of beeing lost inside a 
>vicious circle.
>

The closest that I have seen to what you are asking for is the superset /
extension of Oberon-2 that started life as Oberon/L and is now known as
Component Pascal. There is a section "String Support" in the document "What
is New in Component Pascal" that also details the other extensions and
differences:

www.oberon.ch/pdf/CP-New.pdf

You can download the full version of the software including all source code
from:

http://www.oberon.ch/blackbox.html

There is also a version callled Gardens Point Component Pascal that runs on
the JVM and .NET. The .NET version has ARRAY OF CHAR / System.String
conversions so that you can use .NET's built-in System.String data type and
its many thousands (ok - maybe I exaggerate a little!) of related functions.

http://plas.fit.qut.edu.au/gpcp/


>* Why no dynamic array in Oberon?

Wirth's most recent Oberon-07 ARM compiler does have one-dimensional dynamic
arrays but this is implemented as an extension - it is not defined in the
language:

  http://www.inf.ethz.ch/personal/wirth/Articles/Oberon.html

My understanding is that he intends the Language Report to define a language
that is implementable as widely as possible WITHOUT ANY SUBSETS. Extensions
are OK. As long as you stick to the features defined in the language report
your code should be as portable as is practically possible (far more so than
is possible with C, say).

Our Oberon-07 development system (Astrobe) supports the development of
embedded software for ARM microcontrollers which can have as little as 16K
of ROM for program code and 2K of RAM for data so a language that includes
features that mandate a garbage collector for reliable operation is
obviously out of the question ;-) 

  http://www.astrobe.com

In the version of the Oberon-07 ARM compiler used in Astrobe we currently
only support local dynamic arrays. The syntax is:

  ArrayType = "ARRAY OF" type.

e.g.
  PROCEDURE P();
  VAR
    counts: ARRAY OF INTEGER;
    weights: ARRAY OF REAL;
    alarms: ARRAY OF Event;
    ...
    ...
   
The length of a local dynamic array is established by a call to NEW with a
second parameter indicating the desired number of array elements. For
example: 
    
  NEW(counts, 100)

The great advantage of local dynamic arrays is that they can be safely
allocated on the stack. Thus no garbage collector or special treatment is
required to free their memory when the procedure terminates. This allows the
most efficient use of memory without the associated problems of memory leaks
and fragmentation. 

Regards,
Chris Burrows

CFB Software
http://www.cfbsoftware.com