Re: OOC Core Library

[Sander van der Wal <svdwal@xs4all.nl>]

> 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.

The advantage of including In and XYPlane is that one can run the
examples in 'Programming in Oberon'. No need to use them in the
compiler itself. This should probably at the discretion of the
porter.

>   Modula-2 DIS: Very complete library.  No surprise after all this
> [Knip]
>   Modula-3:  Don't know it.  Can anybody comment on the M3 libs?

I don't know these libraries.

>   Other Oberon compilers:  These come in two flavors, namely as part
> of a whole system or as stand-alone compilers.  
>   I don't know any stand-alone compilers (o2c doesn't count), and most
> of them orientate their libs at the Modual-2 DIS.  

I only know pOt. It hardly has a library, but it is based on the
original Oberon system.

> 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

Looks good. Some thoughts

- Files: 
  I think we need at least the following visible attributes:
  - a Filename to identify it.
  - timestamp (date & time) of last modification (for make)
  - size (in bytes)
  - access for the user running the program that accesses the file
    (reading and writing).   
  they are all read-only.
 
  methods 
  - creation (which can fail)
  - deletion (which can fail)
  - testing whether it exists.
  - associociating readers and/or writers. a reader can only be 
    associated when the user has read access, a writer can only be 
    associated when the user has write access. Writing to a file
    can increase its size. Adding a reader or a writer can also fail
    because of other restrictions.
  - copying (which can fail). Afterwards both Filenames exists.
    associated readers and writers are open for the original
    file but closed for the copy.
  - renaming (which can fail). This means a file is known afterwards
    with the new Filename. The old Filename doesn't exists anymore.
    Associated readers and writers are kept open. 
  - setting its length, independent of writers.
  - remove all readers and writers from all the files the program/command
    has opened.
  
  other stuff
  - I'm not sure whether there should be a directory system.
  - The Files.Register trick of Oberon is a bit expensive to implement
    on the file systems I know (Unix, DOS, RISC OS). I think a 
    module TemporaryFiles is easier.

- Filenames:
  at least three kinds of 'name parts' (each of which can be empty):
  - a 'place' part or an array/list of places.
  - a 'leafname' part
  - an 'extension' part

  - separators should be invisible. 
  - a Filename can be turned into a string. This can fail
    for syntactic reasons (too long, illegal characters etc).
  - a string can be turned into a Filename. This can fail for
    syntactic reasons. The extension one wants the file to have
    should be a parameter. This is convienient when the user 
    does not add the extension on the command line and there
    isn't an extension specified. 
    
    (note: RISC OS doesn't have the concept of extensions, but the 
    convention is to use a directory: e.g. the c file dir/hallo.c on
    unix is called dir.c.hallo on most RISC OS. On the other hand I 
    can read and write DOS floppies, Unix TAR files, etc directly 
    and in that case the extension should be the characters after the 
    dot.)

  - Filenames can be tested for equality. This hides the
    fact that not all systems have case-sensitive names 
    (file 'a' is equal to 'A', or not etc).
    Users should assume the worst case (not case-sensitive).

  - RCSFilenames should be a separate module extending Filenames.
    Not all systems support the ,v convention. 

- RTS (access to the commandline and starting a program)
  - argument separators should be parsed according to system 
    conventions ( -, / etc). The argument separators should be 
    invisible. A program should supply a list of acceptable
    argument names. 
  - arguments are read-only.
  - Called programs are not dynamically linked with the calling 
    program.

I also think we need a runtime linker/loader like the module 
'Module' in the Oberon system. Otherwise the advantages of 
dynamically linked modules are lost. Whether a port supports
it is another matter. This is useful when one wants to build
a cross-compiler, and it is a big plus for Oberon-2 compared
to C++. 

-- 
Sander

These systems people never changed. They could work miracles, but at the
same time they claimed perfectly reasonable requests were impossible.