[Oberon] string manipulation

[spir]

On Wed, 23 Jun 2010 10:07:13 +0930
"Chris Burrows" <chris at cfbsoftware.com> wrote:

Thank you very much for this extensive reply.

> >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/

Right, I will follow the pointers. A language that defines a literal notation, "string", without any corresponding data type, seems to me rather strange. This is the only case in Oberon, I guess (even chars have a type).
The same applied to Pascal (even extended IIRC) but concrete implementations for real-world (all I know of, at least) _did_ introduce a string type.
The issue is, as I see it, and if I'm right: one can construct such a handy abstraction in Pascal or Oberon but it is then close to useless since all the language's constructs and builtin tools simply do not know it (assignment, I/O, conversions...). So that it's not enough to build the abstraction, a dedicated compiler is needed that will, for instance, construct a String when reading a string literal, instead of an internal representation mapping to no user-available type. This is to oppose to a string toolbox simply extending Oberon-defined procs & funcs and operating on open arrays of char as formal parameters.
So, to sum up: a kind of background, transparent, magic is needed to make a String type useful (implemented in the compiler itself, not built on top of the language as is). But I would be pleased to know I'm wrong on this so as to be able to build one, for and in "standard" Oberon-2.

> >* 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

Great. So, I may be wrong. Hope I can find the source and watch how it is implemented.

> My understanding is that he intends the Language Report to define a language
> that is implementable as widely as possible WITHOUT ANY SUBSETS.

What do you mean?

> 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

This would require forbidding pointers to records and arrays, no? Otherwise deallocation is left to the user and thus "reliable operation" cannot be ensured...

> 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)

Close to perfect :-) I guess since it is defined as local-scope only feature, one cannot return an open array as func result (unless it is assigned to an open array VAR of a higher-level procedure?). But the ability to define one VAR as open array is already a huge step in terms of programmer-friendliness.
I'm surprised this is not a standard feature of Wirth language, since as I see it this does not reduce language safety: the size must be bound for concrete use of the VAR; checking (eg array bounds) is simply done at runtime instead of compile-time. This fact makes checking slower and delays error recognition, but does not really makes the language less safe; and anyway, this is programmer choice.
 
> 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. 

Seems to be a sensible choice, esp. for embedded software. (For design choices toward light, practicle and efficient software in the field of embedded programming, but in a highly flexible dynamic language, Lua is a good source of inspiration, I guess.)

> Regards,
> Chris Burrows

Denis
________________________________

vit esse estrany ☣

spir.wikidot.com