Re: [ooc-compiler] C interface problems

[Michael v. A. <Mic...@de...>]

"August" <fus...@te...> writes:

> [...]
> I also skimmed through your GL.Mod file and noticed that literal
> values are defined for (macro) constants. Isn't it possible for the
> OOC compiler to get the values from the C header file?

We do not include arbitrary header files as a rule.  The Oberon code
cannot use the definitions in the header files, while it can use a
constant definition from an INTERFACE file.

> Moreover I tend
> to dislike all but the absolutely necessary Oberon-2 extensions*, so I
> would prefer to rename all identifiers to valid Oberon-2 identifiers
> (no underscores) that follows the standard naming scheme and keep the
> definitions in three different modules: GL.Mod, Glu.Mod and
> Glut.Mod. The conversion rules are very regular (thanks to the
> regularity of the OpenGL interface):

The hardest part of interfacing to an external library is to use it
correctly from within a foreign programming language with foreign
ideas about procedure signatures.  For example, an ARRAY OF X in
Oberon is something different than an X[] in C, and certain uses of
pointer parameters in C cannot be expressed in Oberon-2 at all.  To
widen the distance between the original C interface and the translated
Oberon interface by changing the naming convention would make things
harder still: the C programmers (who know the interface) would need to
learn the new names, and the Oberon-2 programmers (who need to learn
the interface) would need to translate every name they find in the C
documentation to the one used in the Oberon-2 modules.

The one exception I would make to the rule of keeping names as close
as possible is to strip out a common prefix into a module name.  That
is, if a name is "Prefix_Foo", then I would recommend to make it
available to client code as "Prefix.Foo", instead of
"Prefix.Prefix_Foo".

-- mva