🚀 go-pugleaf

In article <BAFE9C2140000681@brfapesp.bitnet>, UNBCIC@BRFAPESP.BITNET writes:
|> I couldn't find the MS-DOS Oberon in the ftp site at Zurich. Could anybody
|> help me?
|> 
|>                               (8-DCS)
|> Daniel C. Sobral
|> UNBCIC@BRFAPESP.BITNET
|> 
|> P.S.: I know it isn't good, but is for learning purposes.


I just don't understand the "it isn't good" statement.  There is only ONE
known bug in the compiler, and it and its libraries have been in use by
many individuals since 1989!   True it doesn't support dynamic loading
and garbage collection, but that is because most DOS users have told me
they don't want such things.  They want a well behaved application program
which won't make it impossible to keep running Lotus or whatever. The
code generation is excellent, everything runs fast, and I've seen 
several impressive applications written on it, one of which is going
commercial by the fall.  The explanitory note I received from ETH was
that they have a policy that only software they write is going to be
housed on their servers.  All the other places have been happy to keep it.


-- E. Videki  (author of Oberon-M)



PS: The single known bug is the one reported elsewhere in this newsgroup.
Specifically, when you have an open-array of pointers, and index that
array, the automatic dereferencing gets a little too ambitious and 
dereferences the indexed array element.  Thus, the following statement
will get a type incompatibility error:
           ptrvar :=  arrayofptrs[someindex]

it is acting like  ptrvar:=arrayofptrs[someindex]^  .  This only 
applies to open-arrays.  If you have a fixed array you can work around
this.  If it is critical, you can remember that range checking won't
stop you from going to a very large array (larger than the type definition).
I've already done the fix, and on the next distribution it will appear
at all the sites.     --EV