Re: OOC Core Library

[Mike Griebling <grieblm@trt.allied.com>]

> 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

The main reason for including variable argument lists is not so much
for the printf/scanf support but rather some OSes (like AmigaDos) depend
on variable argument lists for implementing many of the interfaces to
the OS and windowing system.  Granted, it is possible to pass arrays of
parameters as well, but it seems more elegant to give the user a choice
of implementations.

Michael G.