🚀 go-pugleaf

75742%novell1.rz.fht-mannheim.de@USENET.ZER wrote on Thu, 04-02-1992 at 14:05 h
(Marc Wachowitz)
under the subject 'Re: Oberon-2 Compiler for VAX/VMS (Alpha':

> In article <23U6763F7Y@tron.gun.de>
> g_dotzel@tron.gun.de (Guenter Dotzel) writes:

> >LONGSET would impose compatability problems with SET.
> >Should we allow the conversion with LONG(set) and SHORT(longset)?
> >Amiga Oberon-2 has LONGSET too (how does Fridtjof Siebert handle this)?

> [...]
> >SHORTINT <= INTEGER <= LONGINT <= REAL <= LONGREAL <= G_GFLOATING <= H_FLOATING
> [...]
> >For example, LONG(LONG(LONG(LONG(LONG(LONG(shortint)))))) would be of
> >type SYSTEM.H_FLOATING

MW> Instead of this kind of horrible conversion chains, I'd just use a predefined
MW> standard procedure `VAL(Type, value)', which converts `value' to `Type' iff
MW> the type of `value' is included in `Type'.

Marc,
I've already got a private reply to all my questions from ETH-Zuerich
last week. I've included a slightly edited summary of the reply below.

Oberon's VAL is what ISO Modula-2's CAST is. So VAL doesn't help in conversion, 
since SYSTEM.VAL does a cast (i.e.: type coercion)!

MW> It's more elegant (IMO at least), and allows portability between different
MW> platforms by replacing the right hand side of some central type definition
MW> (assuming the program is written with portability in mind, as usual :-).

See summary below.

> >Should we put Oberon-2's pervasive types SHORTINT and LONGINT into SYSTEM
> >in favour of a single integer type INTEGER as in ISO Modula-2?

MW> If you expect to compile code from other platforms, I doubt that would please
MW> users.

See summary below ("Oberon-2 and *not* ISO Modula-2 plus some OO features"!):


      -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
      ETH-Reply Summary (ludwig@inf.ethz.ch)
----->-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

>Oberon-2 has SHORTINT INTEGER LONGINT SET, with size in bits on
>Ceres/ETH    8        16      32      32
>VAX-native   8        16      32      32
>Alpha-native 16       32      64      64 ?
              ^
Wrong! Use 8 bits! The Alpha has no 16 bit Operators! SHORTINT should be
compatible with CHAR! LONGINT and SET ok.

Don't support D_, G_, H_FLOATING in the first place.
IEEE REALs/LONGREALs all over the place [called S_, T_FLOATING on Alpha]!

>Complex data type and pervasive functions?

Don't put them into SYSTEM! Make them proper types and functions. Small
extension of Oberon-2, no problem. Or, put them into a 'Complex' module known
to the compiler. Therefore, an IMPORT Complex clearly indicates the
non-portability of the code.

>Should we put Oberon-2's pervasive types SHORTINT and LONGINT into SYSTEM
>in favour of a single integer type INTEGER as in ISO Modula-2?

No! It's clearly stated in the Oberon Report what numeric types are expected.
If you don't support them then it's no longer Oberon!

>Currently, SYSTEM.VAL in Oberon-2 is what SYSTEM.CAST is in ISO Modula-2.
>This is inconvenient and already caused confusion. 
>We'll provide SYSTEM.CAST in addition to SYSTEM.VAL in the H2O implementation.

Please don't. Again, in the Oberon Report, SYSTEM.VAL is defined and expected
to be the only conversion function. If you provide two functions, inconvenience
and confusion is doubled! Furthermore, this is Oberon-2 and *not* ISO Modula-2
plus some OO features! Don't try to clutter Oberon with additional, unneeded
features. Let's adhere to the standard as described in the Oberon-2 report!
BTW: SYSTEM.VAL is used rarely, anyway.
<-----

     I like these answers! There seems to be a tremendous interest in avoiding
Oberon-2 imcompatabilities from the beginning. I'm understanding that you are
not allowed to call your compiler "Oberon-2" if you make changes to the Oberon-
2 language as defined in The Oberon-2 Report, written by H. Moessenboeck and
N. Wirth.


Cheers, G~unter

Guenter Dotzel, ModulaWare GmbH, Wilhelmstr. 17A, D-W 8520 Erlangen/F.R.Germany
Tel. +49 (9131) 208395, Fax +49 (9131) 28205. 
E-mail/Internet:  g_dotzel@ame.nbg.sub.org 
E-Mail/CompuServe:100023.2527@compuserve.com