[Oberon] Procedure variables and local procedures

[Srinivas Nayak]

>> TYPE
>>   CharPtr = POINTER TO ARRAY OF CHAR;
>> VAR
>>   p : CharPtr;
>> BEGIN
>>   NEW(p, 1234);

> Not exactly. Oberon-07 doesn't allow ARRAY OF <type> in a type or variable declaration (excluding open array parameters which are a different concept). Nor does Oberon-07 allow POINTER TO ARRAY - pointers can only point to RECORDS (which can have ARRAYs as fields).

Sorry for my ignorance; how do we achive this in Oberon-07?

It is similar to:
char* p;
p = malloc(1234);
in C.


With thanks and best regards,

Yours sincerely,
Srinivas Nayak

Home: http://www.mathmeth.com/sn/
Blog: http://srinivas-nayak.blogspot.in/

On 10/01/2017 09:42 AM, Chris Burrows wrote:
>> -----Original Message-----
>> From: Chris Burrows [mailto:chris at cfbsoftware.com]
>> Sent: Sunday, 1 October 2017 9:52 AM
>> To: chris at cfbsoftware.com
>> Subject: FW: [Oberon] Procedure variables and local procedures
>>
>>
>> TYPE
>>   CharPtr = POINTER TO ARRAY OF CHAR;
>> VAR
>>   p : CharPtr;
>> BEGIN
>>   NEW(p, 1234);
>>
>> Ah I see, you are referring to Oberon-2 (1993)
>> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.37.9417&rep=
>> rep1&type=pdf
>>
>> NW designed two languages:
>> - the original Oberon
>> https://www.inf.ethz.ch/personal/wirth/Oberon/Oberon.Report.pdf
>> (1990)
>> - and his revision Oberon-07
>> https://www.inf.ethz.ch/personal/wirth/Oberon/Oberon07.Report.pdf
>> (2013/16)
>>
>> In the original Oberon, NW defined in the low level compiler module
>> SYSTEM the procedure NEW(v, n).
>> In Oberon-07 this is not existing anymore. As Andreas Pickelbauer
>> demonstrated, this functionality can be introduced with Oberon-07
>> without changing the language.
>
> Not exactly. Oberon-07 doesn't allow ARRAY OF <type> in a type or variable declaration (excluding open array parameters which are a different concept). Nor does Oberon-07 allow POINTER TO ARRAY - pointers can only point to RECORDS (which can have ARRAYs as fields).
>
> If these syntax changes were introduced they would need to be considered as language extensions. There would also be the question of whether the feature would be restricted to single-dimensional arrays, what notation would be used if multi-dimensional arrays would be used, how many dimensions would be allowed, what are the rules of assignment compatibility issues etc. etc.
>
> I have seen various Oberon-style implementations of this over the years e.g.
>
>    ARRAY OF ARRAY OF ARRAY 3 OF INTEGER
>
>    ARRAY *, *, 3 OF INTEGER
>
> etc.
>
> All in all it is far from a trivial matter. Considering that the sort of low-level system software that Oberon-07 is suited to rarely needs such a feature then I can understand why Wirth hasn't yet bothered to include it.
>
>>
>> Whether the index i of the expression a[i] shall be checked is not
>> defined in Oberon either. This is left to the implementation as you
>> might want your code to be finetuned for speed (no checks) or
>> security (with checks). Oberon-07 offers different methods for your
>> concern:
>>    ASSERT( (0 <= i) & (i <= 255) ); b := i;    or
>>    b := i MOD 256;
>>
>
> Alternatively, and, most likely, more efficiently:
>
>    ASSERT(i DIV 256 = 0); b := i;
>
> Note that depending on the context / requirements the latter might need to be either:
>
>    b := ABS(i MOD 256);
>
> or
>
>    b := ABS(i) MOD 256;
>
>> I find BYTE quite useful.
>
> I'd go further than that. I find BYTE *absolutely essential* for embedded system software development. Hardware engineers have a particular talent for defining weird and wonderful data items. For example a particular temperature sensor I use returns the data in this form:
>
> (* The result is a 10-bit 2's complement integer: result:9:2 := msb:7:0, result:0:1 = lsb:7:6 *)
>
> Consequently I often find myself looking forward to the day when we might have BIT ARRAY and BIT FIELDS constructs in Oberon.
>
> The usual notion of Language portability is generally a non-issue for Oberon-07 in practice. A programmer cannot afford to make any assumptions about which byte of an integer a byte value is to be stored in. When dealing with data structures like this the programmer needs to know the excruciating details of BYTE and BIT ordering and needs a language and compiler (e.g. Oberon-07) which generates predictable code according to the programmer's instructions.
>
> Any resulting algorithm is non-portable by definition from one manufacturer's sensor to another - or even two different sensors from the same manufacturer! Wishing for anything else is just dreaming.
>
>> In the original Oberon, the comparable
>> SHORTINT was signed, BYTE is unsigned. When e.g. parsing TCP packets
>> and you wanted to calculate the port nbr, you couldn t easily use
>> SHORTINT. So, I often misused CHAR, as ORD(c) returns an unsigned
>> value. As in the majority of cases bytes are treated unsigned, BYTEs
>> makes the code a little bit more intuitive to read.
>>
>
> I totally agree.
>
> Regards,
> Chris Burrows
> CFB Software
> http://www.astrobe.com
>
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>