[Oberon] A new dialect? Oberon+ (OBX)
t.pearson at mac.com
Sun Jul 25 23:06:16 CEST 2021
> On 25 Jul 2021, at 14:23, Chris Burrows <cfbsoftware at gmail.com> wrote:
> On Sun, Jul 25, 2021 at 10:07 PM Diego Sardina <dsar at eml.cc> wrote:
>> This is not a dialect but a whole new language.
>> The author should use a new name, not Oberon.
> I agree. In the documentation it is also referred to as Obex. That
> might be a suitable alternative name?
>> He implemented all those features that programmers love, ignoring all implications they may cause.
>> Just for example: Why enumeration? Did they find a solution for the problems they may cause in separate compilation?
> For those not aware of these issues they are discussed in the
> document:'Programming Without Enumerations in Oberon' by C. Lins,
> published in SIGPLAN NOTICES V25, #7, July 1990:
> Chris Burrows
> CFB Software
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
The paper is an interesting viewpoint: I suspect many of the arguments could be made equally well, almost 'as is', -for- enumerations rather than against. I hold my hand up over never having had to professionally program in Oberon, and in general I love its simplicity; but I do wonder if Oberon takes simplification too far by axing this construct: you lose many good things.
- having manually to create unique numerical constants for each enumerated value… in fact, for a long list of constants being used to represent enumerated values, it feels like the safest thing would be to generate the source using a script
- no cohesion of related values — if you were to use an enumeration as an error code, a type checker would normally ensure you weren’t trying to pass an unrelated value — be that another constant representing a colour of the rainbow or the square root of 4
- no opportunity for compilers to help ensure completeness (eg in CASEs, etc.)
However, I didn’t design the language and so I didn’t get to make the design choices :-)
More information about the Oberon