Re: OOC Core Library

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

Mike G write
> mva wrote:
  [knip]
> > of the section determines what Oberon-2 object (ie, a type, a
> > variable, a procedure, etc) is modified by them.  It's the back-end's
> > task to to parse the stuff inside the brackets.  That means that every
> > back-end has full freedom in the choice of its supported flags.
> 
> But that kind of anarchy would make code which interfaces to external C
> libraries non-portable.  I thought the whole purpose of using these flags
> was to make the code portable.  To help this effort along, I suggest that
> maybe all the code generators could share a common set of flags that they
> all support.  For example, a standard C interface might be:
> 
>   PROCEDURE ["C"] FormatString ["sprintf"] 
>         (s, template : ARRAY OF CHAR [...]): LONGINT;
> 
> Here, the [...] indicates that additional arguments are allowed to be passed.
 
I'm in favour of a portable syntax for specifying external linkage 
specifiers (["C"]) and external identifiers (["sprintf"] etc).
External libraries are a bit difficult to specify portable (they aren't 
called the same at each system, eg on RISC OS the shared C library is 
called stubs instead of libc). 
I'm not sure whether it is possible to portably specify interfaces
to such routines, though. For instance in the example above (I presume
there should be a ; between the CHAR and the [...]) the backend has to know
that s and template are C strings that must be passed as 'const char *'.
This seems to mean that we must define a mapping between the C parameters
and the Oberon parameters for example:

  Oberon                               C
  s: ARRAY OF CHAR                     const char *s
  VAR s: ARRAY OF CHAR                 char *s
  s: POINTER TO ARRAY OF CHAR          const char **s
  VAR S: POINTER TO ARRAY OF CHAR      char **s
  s: ARRAY 10 OF CHAR                  char s[10]
  
etc. (Not everthing is correct I'm afraid, but I hope you'll see what I
mean)

I'm not happy with variable argument lists. I would suggest we don't 
bother with the printf/scanf family, because the same functionality
can be achieved in Oberon. Other functions like ioctl() or open() could 
have as many external variants as possible combinations of variable
arguments. This gives much better type-safety.

-- 
Sander

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