[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Interfacing to C (was: OOC Core Library)
mva wrote:
> > From: Sander van der Wal <svdwal@xs4all.nl>
> > ...
> > etc. (Not everthing is correct I'm afraid, but I hope you'll see what I
> > mean)
> >
> ...
>
> Interfacing to a language that doesn't share Oberon-2 type rules and
> calling conventions has some other problems. Take for example C:
> * structs
> ...
> 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.
Maybe we can make things easier if we state that the responsibility
for supplying the correct information to a external routine lies
with the calling language, ie if Oberon calls C the Oberon compiler
or programmer must make sure it passes the correct information.
I think that if one can add Oberon code and external C declarations
in an interface module to some C code one can go a long way in providing
an Oberon-like interface to a C module. I think that the Oberon-
interface is important and should be easy to use portable, whether the
implementation of the module is portable is of lesser concern.
For example one should be able to say something like
VAR statbuf: Unix.StatDesc;
IF Unix.Stat(filename, statbuf) = 0 THEN
...
Whether the module Unix looks like
MODULE Unix;
...
TYPE
StatDesc* = RECORD
LONGINT StDev*;
....
END;
PROCEDURE ["C"] realStat ["stat"] (fn: ARRAY OF CHAR;
bufadr: LONGINT): LONGINT;
END realStat;
PROCEDURE Stat*(fn: ARRAY OF CHAR; VAR buf: StatDesc): LONGINT;
BEGIN
RETURN realStat(fn, SYSTEM.ADR(buf.StDev);
END Stat;
or
....
PROCEDURE ["C"] Stat* ["stat"] (fn: ARRAY OF CHAR;
VAR buf: StatDesc): LONGINT;
END Stat;
is not that important, I think.
--
Sander
These systems people never changed. They could work miracles, but at the
same time they claimed perfectly reasonable requests were impossible.