Re: Re: Platform-Specific Extensions

[I omitted the following quote in mail this is a reply to a reply to - AR]

Wolfgang Thaller <[email protected]> writes:
> I suggest that we follow the example of OpenGL and mark extensions
> using a suffix to the name, e.g.
> mkXmForm_EXT, loadNibFile_EXT, etc.

Alastair Reid writes:
>> One little detail: what about datatype declarations?

Axel Simon <[email protected]> writes:
> I think this is not a problem at all. As far as my grasp of our task
> is concerned, we are just defining an API (CGA). That means we have
> a bunch of modules declaring data types, functions and some
> semantics but these modules don't do anything. If the user wants to
> build an application (s)he has to choose one specific backend
> (hs-aqua, gtk2hs, HToolkit, etc.) and link to it (using -package
> hs-aqua or similar). Then it is no problem to have data types with
> more constructors in each backend.

Of course, the code will compile with no problem at all.  The idea of
having a standard way of marking backend-specific extensions is not to
solve a compilation or typechecking problem but to accomplish what we
might call a social or software-engineering problem: helping people
understand when they are using a non-portable extension.

As Wolfgang points out, this is done in OpenGL (which has a similar
problem of trying to provide a common frontend to a set of backends
with differing capabilities).

You'll see similar goals being accomplished if you use the -ansi flag
with gcc (warns about use of non-ansi features), the extension
qualifier in gcc (can be used to tag functions, variables, types,
etc. as being extensions beyond standard C), etc.

Hugs' +/-98 flag and GHC's -f[no]glasgow-exts serve a similar goal.
You might even consider GHC's 'deprecated' annotation as serving a
similar goal.

--
Alastair Reid