Re: [ooc-compiler] C interface problems

[Frank C. <fj...@wo...>]

On Fri, Nov 05, 2004 at 02:13:02AM +0100, August wrote:

> 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.

What standard naming scheme? Nothing about Oberon is standardised.

The restriction on valid identifiers is one of the more irritating quirks
of the Oberon family of languages. Restrictions in Oberon are usually
justified on the grounds of simplicity or efficiency, but neither applies in
this case. The modifications to the compiler to permit C-style identifiers
are absolutely trivial. The effort required to translate C-style identifiers
into restricted Oberon identifiers is not.

> The conversion rules are very regular (thanks to the regularity of the 
> OpenGL interface):

Not all C APIs have such regularity. These rules can and do produce
identifier clashes and even illegal identifiers in other APIs. It took me
five minutes to find several examples in one module of the Oberon interfaces
for AmigaOS 3.0:

MEMF_CLEAR => clear (memClear used instead)
CMD_CLEAR  => clear
MEMF_24BITDMA => 24BitDMA (mem24BitDMA used instead)

Note that if the value of clear is used in place of memClear in an AmigaOS
memory allocation function call the most likely result is 'a visit from the
Guru' otherwise known as a total system crash. A programmer blindly applying
the conversion rules to C code taken from API documentation or example code
is highly likely to make this error.

Converting identifiers is therefore not only tedious and error-prone, it can
lead to the introduction of serious bugs.

> *If we want Oberon-2 with lots of extensions then we might as well 
> turn to Eiffel.

All the Oberon languages are the products of academic research projects and
cannot be considered complete general purpose programming languages outside
of the scope of the various Oberon operating systems. Extensions are
inevitable and necessary.

I do think there is an argument that the extended language implemented by
the OOC compiler is at least as far from the base Oberon-2 as Component
Pascal and so deserves a name of its own.

Frank Copeland
-- 
Stamp out philately.