Re: [ooc-compiler] Oberon-2 standard

[Michael v. A. <Mic...@de...>]

"August" <fus...@sp...> writes:

> Concerning the posting from Gregory Gelfond and the answer from Michael van
> Acken
> 
> > ...
> > In general, the resemblance between the libraries of oo2c and the
> > original documentation of the Oberon System is superficial.
> > ...
> 
> Wouldn't it be (very) desirable to make OOC conform to the Oakwood
> guidelines at least when it comes to the basic libraries? As stated in the
> report:
> 
> "The intention is that all implementors should offer support for Oberon-2 to
> at least the ETH specification standard and also offer an implementation of
> the basic library modules."

I dropped the Oakwood modules from the compiler distribution 1.5 years
back and nobody seems to mind.  In all this time, you are the first to
raise that topic.

> I must say that even if the OOC version of the IO functionality etc. is more
> efficient, I find the idea of redefining the interface of some of those
> standard modules a bit strange (I don't think anyone would ship a C-compiler
> with a library header named `stdio.h' that differs from the standard ansi
> `stdio.h' specification).

Comparing the Oakwood guidelines to one of the ISO C standards is a
bit far fetched, isn't it?  Putting them side by side, even the
difference in sheer paper weight should be most impressive.  Don't get
too impressed with the word "standard".  Oberon (which was hardware,
operating system, and programming language in the beginning) was, and
probably still is, a vehicle for research and teaching -- but not for
"standards".

> Why not call the non-compatible modules OOCFiles, OOCIn etc or
> something completely different? One risk with the current modules is
> also that users may think they are using standard libraries since
> the names coincide. Another solution would be to make the OOC
> version of each of these modules a true superset of the
> corresponding standard module and then require a special compiler
> option to allow the extra functionality.

All programms I have seen that were both Oakwood compatible and
portable were either student exercises or toy programs.  To have a
program that runs both on the original Oberon System and in an
environment like Unix is a challenge.  Take for example command line
arguments, interactive input, and long running programs.  OS has no
command line, and it (and the Oakwood modules) has no idea of command
line arguments.  Interactive input is also a different thing in an
environment where modal dialog is the exception and contrary to the
basic design.  And long running programs either grab the system
completely or must arrange themselves with the OS task system (not
covered by Oakwood).

It is pretty safe to assume that there are very few users that program
for the Oakwood guidelines.  On the other hand, if you want to target
that particular niche of the Oberon crowd, you can always put together
a compiler distribution that offers only Oakwood modules with
appropriate names and functionality.  With the exception of a small
number of modules that essentially constitute the compiler's run-time
system, all modules that make up the basic library can be removed or
replaced.

-- mva