[Oberon] Oberon-3

[Oleg N. Cher]

Hi Jörg,

Unfortunately, Component Pascal does not support ORD() for BOOLEAN. 
Since we have the BITS() operation there, it is good to have a pair 
operation ORD(set) for converting bits to a number.

In Oberon-3 I supported ORD() for SET and BOOLEAN, as found it useful.

Ilya Ermakov noticed that ORD(procedure) is useful as a unique stamp 
number for unambiguous identification of procedures. Such operation does 
not look dangerous to be moved into SYSTEM, although it can hardly be 
called portable. Besides this can cause theoretical problems if ORD() 
returns a 32-bit result and a system has 64-bit address space.

So in general, I wasn't going to implement ORD() for other types than 
these. Although, of course, it will be interesting to hear different 
opinions on this issue.


Jörg пишет:
> Oleg
> 
> I read in your Oberon-3 description that you support ORD() on several types.
> Oberon-07 defines ORD() on CHAR, BOOLEAN and SET.
> NW's compiler supports ORD() on more types as well, but this is undocumented.
> Generally, ORD is a little dangerous, as ORD returns implementation dependent values, and hence a code using ORD might not be portable.
> 
> NW's Oberon-07 compiler (ORP.StandFunc) supports ORD() on
> BYTE, BOOLEAN, CHAR, INTEGER, REAL, SET, POINTER, NIL, PROCEDURE
> 
> Puristically, it is better to use SYSTEM.VAL(INTEGER, x) instead of ORD(x) as SYSTEM flags the implementation dependency.
> 
> It is again (like the semantics of suffix "H") one of the undocumented compiler features NW uses in his own code.
> With a strict compiler implementing ORD() according to the Oberon-07 report, you cannot compile Texts.Mod and System.Mod in its current form.
> 
> br
> Jörg
> 
> Am 04.11.20, 10:47 schrieb "Oberon im Auftrag von Oleg N. Cher" <oberon-bounces at lists.inf.ethz.ch im Auftrag von allot at bk.ru>:
> 
>     August Karlstrom пишет:
> 
>     >>    Oberon-3 (experimental dialect with constant arrays and "proper FOR")
>     > 
>     > Oberon-3 seems to be so obscure not even Google can find it.
> 
>     I may have shown some impudence in taking this name. But I didn't plan 
>     to make my own Oberon dialect, I just needed some extensions for my 
>     activities. I hope this doesn't cause too much anger among those who 
>     respect Prof. Niklaus Wirth and his associates.
> 
>     In any case, this development is unlikely to spread too widely and will 
>     become very popular. So the name "Oberon-3" can be considered vacant for 
>     further achievements.
> 
>     Thanks for understanding.
> 
> 
>     > 
>     > 
>     > -- August
>     > -- 
>     > Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>     > https://lists.inf.ethz.ch/mailman/listinfo/oberon
> 
>     --
>        Oleg N. Cher
>     --
>     Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>     https://lists.inf.ethz.ch/mailman/listinfo/oberon
> 
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon