Re: OOC Core Library

[acken@informatik.uni-kl.de]

   Date: Fri, 1 Dec 95 06:35:57 EST
   From: Mike Griebling <grieblm@trt.allied.com>

   > [snip]

   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 never set that each back-end should make up its own set of flags.
Of course there should be some agreement on a `standard' set,
especially on those flags that change the semantics of Oberon-2
objects.  

Example: Declaration of a external C record type.
  MODULE ["C", "libxyz"] Foo;
  
  TYPE
    CStruct* = RECORD [NOT_EXTENSIBLE]
                 ...
               END;

  END Foo.

This flag modifies the standard Oberon-2 record type to prevent using
Foo.CStruct as another record's base type.  That means that the
front-end has to perform an additional check when extending a record,
ie it has to test if the `structNotExtensible' is set in the base
type's flags.
  All those flags that result in additional semantic checks in the
front-end have to be known beforehand and will (probably) hardcoded
into the front-end.  The front-end expects these flags to be set in
the object's reps. type's data structure.  The back-end takes care of
parsing the [...] parts and putting the flags into the data structure.

Note that the front-end doesn't support multiple [...] for a single
Oberon-2 object.  Michael's example from above has to be written as 

     PROCEDURE ["C", "sprintf"] FormatString
	   (s, template : ARRAY OF CHAR [...]): LONGINT;

-- mva