Re: Interfacing to C (was: OOC Core Library)

[acken@informatik.uni-kl.de]

>  From: Sander van der Wal <svdwal@xs4all.nl>
>  
>  ...
>  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). 

Portability of system dependent modules.  Somewhat paradox, isn't it.
But I agree that the back-end people should agree on notation that is
shared by all back-ends, but may have extensions to serve the need of
the particular back-end and its underlying OS.

>  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
                                    corr: char *s
>    VAR S: POINTER TO ARRAY OF CHAR      char **s
>    s: ARRAY 10 OF CHAR                  char s[10]
                                    corr: const char s[10]
>    
>  etc. (Not everthing is correct I'm afraid, but I hope you'll see what I
>  mean)
>  
I put the above parameters through o2c and checked the output.  That
provided the `corr:' entries.  

Interfacing to a language that doesn't share Oberon-2 type rules and
calling conventions has some other problems.  Take for example C:
* structs 
are not identical to O2 RECORDS, because they 
  can't be extended, 
  they can't extend another type, 
  parameters are not passed with type tags, 
  can't be type-tested, 
  have no type-bound procedures,
  and pointers to this type are untagged
* unions
no counterpart in O2
* open arrays
no length information available, ie
  LEN cannot be used
  parameters are not passed with length info,
  nested open arrays are not possible
* calling conventions
no implizit type tags (for records) or length information (for arrays)
are passed; may have a different low-level mechanism to pass
parameters (stack vs registers, etc); may allow var args `...'

In short: Interfacing to foreign languages may introduce a whole bunch
of new types for records, unions, arrays, and procedures.  But these
special declarations should be accessed from O2 programs as
tranparently as possible.  Calling a C function should look exactly
like calling a O2 procedure.  The compiler has to hide the differences
as far as possible.

My idea to solve this problem is to map (syntactically) each foreign
type, variable, parameter, and procedure on the O2 syntax (eg, C
struct becomes O2 RECORD) and give them additional flags that signal
how they differ from the standard O2 stuff.  For example the C struct
would have the flags "can't extend", "can't be extended", "no type
descriptor" or "untagged" set.  The front-end knows those flags and
how they influence semantic checks (and--possibly--GSA code
generation).  It would prevent any attempts to extend this type or to
apply a type test to it, but otherwise treat it just like any other O2
type. 

>  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.
>  
I'm not that happy with it either.  But there may be a situation where
someone has to use variable argument lists in order to interface to
the very specific and elaborate C based library he needs for his
project.  I wouldn't like to tell this person that it isn't possible... 
Anyway, var args are already part of the front-end, although I haven't
tested it lately.  So it's up to you if you want to allow var arg
declaration in interfaces to foreign languages or not.

-- mva