[Oberon] concrete use of open array

[Chris Burrows]

>
>-1- form of actual parameter
>
>Since one cannot have a VAR of open array type, what is the 
>actual form of an open array parameter, in the call expression?
>I tried the "[...]" format used in some Pascal dialects to 
>express open array constants, but it is refused.

I think you may have misunderstood the purpose of the open array in Oberon.
It is provided so that you can develop a general procedure that allows you
to process arrays of the same type but different lengths.

e.g. 

TYPE
  DailyCount = ARRAY 7 OF INTEGER;
  MonthlyCount = ARRAY 12 OF INTEGER;

VAR
  passengers: MonthlyCount;
  trains: DailyCount;

In Pascal you would have needed a separate functions for each data type e.g.

  DailySort(VAR data: DailyCount);
  MonthlySort(VAR data: MonthlyCount);
  
After Pascal came Modula-2 (and then Oberon) where you can define a generic
procedure as:

  Sort(VAR data: ARRAY OF INTEGER);

you can then call:

  Sort(passengers);

or 

  Sort(trains);

NOTE: Unlike languages like C you do NOT need to pass an additional
parameter to tell the procedure how long the array is. The Sort procedure
can use the built-in LEN function to access that information.

>Side-question: is there a literal notation for arrays? for 
>records? (eg like pascal consts, or var initialisation)
>

The only literal notation for arrays in Oberon are string constants. This is
a regular thorny question. Just a few days ago I came across a similar
question in the ARMExpress Yahoo Group:

// I'm looking for some feedback on a "quick and dirty" way to add an array
of
// constants to ARMbasic.
//
// VB has a way to initialize and array
//
// DIM x as INTEGER() = New Integer {1,2,3,4}

My response was:

First of all you need to decide what range of tasks you are trying to
support with this type construct, and what it is NOT designed to be used
for.

For your simple small example

{1,2,3,4}

I can't really see that such a feature is necessary. I would have just
initialised this with a loop to make it clear to the reader that there was a
pattern (assuming there is?) to the data. Even if the four values had been
random it is no big deal to have four assignment statements.

It is fairly straightforward to design a system to just handle small
one-dimension arrays of integers but that does not extend well to more
complex data structures e.g. 3-dimensional arrays, arrays of records
(structures) etc. etc. and is also unmaintainable once you go beyond a
number of items that you can quickly count (e.g. 10 or so).

e.g. how long does it take you to tell me what the 19th value is:

{1,5,2,6,4,1,4,7,8,5,4,8,2,6,9,0,5,3,4,2,5,2}

Now, are you *really* sure that was the 19th value?. You have to count at
least twice.

We had to find a way of handling the same situation with Astrobe as the only
structured constant in Oberon-07 is a string.
Also having seen the way this facility is often abused in C - humongous
constant sections that embed images, fonts etc. in source code, using
programs that convert the binary data to a text form, we went for a
different approach in Astrobe.

Typically on a PC system, this sort of constant data would be stored in a
file to be read at runtime or as a 'resource file' embedded in the
executable. The solution we use has features from both. We handle large
blocks of constant data by gathering together all of the relevant data files
(binary data, images, fonts etc.) at link time and appending them to the
linked executable to be stored in Flash ROM when the program is uploaded.

A library module ResData is provided to allow the programmer to conveniently
access the data, as indexed data, from Flash ROM within the program as if it
were data stored in a random-access disk file.

Regards,
Chris Burrows
CFB Software

Astrobe: ARM Oberon-07 Development System
http://www.astrobe.com