[I omitted the following quote in mail this is a reply to a reply to - AR]
Wolfgang Thaller
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
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