[Haskell-cafe] Generating Code

[L Corbijn]

On Sat, Dec 10, 2011 at 11:12 AM, Vo Minh Thu <noteed at gmail.com> wrote:
> 2011/12/9 Stephen Tetley <stephen.tetley at gmail.com>:
>> Geoffrey Mainland did significant work generating C with his GHC quasi
>> quote extension. I'm not sure the status or availability of the code
>> but there was a good Haskell Workshop paper describing it.
>>
>> For the specific problem of OpenGL - as the package already exists I'm
>> not sure a generative approach would actually pay its way
>
> I believe it is the right approach, and the one used originally.
>
> Whenever you will want to add appearing functionalities (from later
> OpenGL specs) or modify something (debugging facilities), having a
> generative approach will pay.
>
> Actually, from the OpenGL spec files, there is a lot that can be done,
> not just OpenGL bindings.
>
> As for the OP original question, I wonder why he wants to add comments
> in the generated code. That code should be a straightforward mapping
> to the original C API. No need to document it. Documentation would be
> good for higher-level bindings but not for one corresponding tightly
> to the specs files.
>
> Of course some documentation about the used conventions and other
> generic properties of the bindings would be usefull, but I don't see
> any reason to generate documentation as part of the generated code.
>
> Cheers,
> Thu
>

Indeed generating documentation for OpenGLRaw is not really a problem,
it could be a nice feature to add a link to the OpenGL documentation
for each imported function. Furthermore, the lack off good support for
documentation makes it impossible to use haskell-src-exts to use
documented haskell code and modify it without losing relevant
documentation.
The lack of CPP and antiquotation (as is pointed to by Geoff) are just
examples of haskell-src-exts being non extenable. For reading and
processing haskell is the rigid syntax structure no problem, as you
only need valid haskell syntax. But when you try to add or modify the
source this will turn into a real problem.

The use of template haskell doesn't solve this, and in my opinion
makes the problems even worse. Code generated by TH can't really be
documented as there is no code yet, nor can it's source be read as
simply as pure code. And last but not least it's not really portable.