OOC Core Library

[acken@informatik.uni-kl.de]

Hello everyone.

Just before the this mailing list got started I was discussing with
Frank the problems he has in getting OOC compiled on his Oberon-A
compiler.  In order to do this he has to port some of the (Unix based)
o2c libs.  Most of the stumbling blocks have been removed for now, but
he suggested to start a discussion on a library for OOC "rather sooner
than later".  I didn't want to begin thinking on libs at the current
stage, but Frank is probably right.  So, here are my first thoughts on
this topic...

------------------------------------------------------------------------

OOC needs a set of library modules.  Just like the compiler itself
they should be designed to support multiple platforms.  There should
be a set of `standard' modules that are available on all targets.  Any
program built exclusively on these modules should compile and run on
every single target machine, most of all the compiler itself.

  I suggest to take a look at existing libraries and take the best
from all of them.  The original Oberon System can be safely ignored,
because its libs are built with the `system' idea in mind, and aren't
suited for a stand-alone compiler.  IMO this leaves the following
possible sources:
  - Oakwood Guidelines
  - Modula-2 Draft International Standard
  - Modula-3???
  - other Oberon-2 compilers

  Oakwood Guidelines: All I/O modules suffer from the Oberon System
background.  The module "In" is in fact a parser (ever tried to read a
line with this module?).  "Files" has terrible error reporting and
makes no use of the O2 type-bound procedures.  "XYplane" and "Input"
are nonsense on most systems.  This leaves the modules Out, Strings,
Math, and MathL.  These are adequate.
  Modula-2 DIS: Very complete library.  No surprise after all this
years of standardization effort.  There are a number of usable
libraries, with one large exception: the I/O facilities.  The DIS
needs 113 pages to describe the 16 modules that comprise them.  I call
that bloated, don't know how you call it.  
  Modula-3:  Don't know it.  Can anybody comment on the M3 libs?
  Other Oberon compilers:  These come in two flavors, namely as part
of a whole system or as stand-alone compilers.  An example of the
first is Oberon/F.  I like how O/F treats files: The type `Rider' is
split into `Reader' and `Writer' and all procedures working on them
are defined as type-bound procs.  This is far more flexible and
powerful than the Oakwood Files modules.  
  I don't know any stand-alone compilers (o2c doesn't count), and most
of them orientate their libs at the Modual-2 DIS.  

  We have to agree on a set of libraries that covers at least the
stuff that OOC is using.  Currently the front-end depends on the
following (o2c) modules: 
  (* string handling *)
  Strings
  Strings2
  (* conversion numeric value from/to textual representation *)
  ConvTypes
  IntStr
  RealStr
  (* input/output *)
  Out
  Files
  (* miscellaneous *)
  Filenames
  Rts (for ArgNumber, GetArg, System)
In order to implement a `make' I'll need facilities to get a file's
time stamp (from Dos.Mod) and to compare time stamps (from Time.Mod).
I don't know if any back-end implementation will add to this list.

Here is my outline for a core library:
- take most library modules from the M2 DIS
- make an object-oriented Files module
- provide modules In and Out
- put together a module `Filenames' that works with Unix, AmigaOS,
  RISC OS (and maybe MS-DOG)
- don't forget to add procedures to access command line arguments and
  to run a command

This is a rather short summary, agreed.  It's just intended to get a
discussion on the core lib started.  I'll collect replies (directed to
the list, please) to this posting for a week or so, and will post a
summary of them (probably next week's Thursday).   
After we've agreed on a general outline we can start to specify module
interfaces... 

Another thing:
Can anybody tell me if the Modula-2 DIS 10514, dated June 1994, is
still current?  And is this document available somewhere on the net?


-- mva