[Oberon] string manipulation
denis.spir at gmail.com
Wed Jun 23 10:34:31 MEST 2010
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
> You can download the full version of the software including all source code
> 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.
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
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 ;-)
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.
> PROCEDURE P();
> 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
> 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.)
> Chris Burrows
vit esse estrany ☣
More information about the Oberon