On Fri, Dec 9, 2011 at 9:17 PM, Erik Hesselink wrote:

On Fri, Dec 9, 2011 at 20:45, L Corbijn wrote:

...

So I'm interested if there are other libraries that are more suitable to the task of generating haskell code for library use, and thus generate 'human readable' exported code (so no TH). I'm also interested in how other projects generate code for their packages.

Since you ask how other packages solve this problem, and since most packages use template haskell, I have to ask: why can't you use template haskell for this?

Another option (also not code generation, but very useful in reducing boilerplate) is generic programming, for example using the 'regular' package, or the new generics in GHC 7.2.

Erik

That's a good question, and maybe I should have answered it the first place. The short answer is, I'm trying to generate modules from scratch (or spec) so there is no module yet to put the template haskell in. But I think, with my limited knowledge of template haskell, that it tries to solve a different problem, to explain it more detailed I'll first elaborate on the problem that I want to solve. I'm trying to do, in general, is generating a package (almost) from scratch by using a specification of what it should be. The specific problem is that the OpenGLRaw package is quite out of date and needs updating. This package is in essence a large FFI import of the OpenGL specification from C. To update it (or recreate it), with it's hundreds of functions and enumeration values, is not only boring but also tedious and error prone work. As there is a specification of all this a better option would be to generate it. The starting point for such generator would be only with a few helper functions and the OpenGL specification. It would then generate all the enumeration values and function imports (split over several modules). The major set of problems for using template haskell is that it doesn't have the correct features, or better said it tries to solve another problem. Template haskell generates code into an existing module, while for this problem there is no module yet to generate it into. Of course I could generate those modules and let template haskell make the FFI imports, but then the problem remains how to generate those modules. So template haskell seems (as I see it) to solve the problem of writing almost the same code twice by generating it from some parameters coded in some source file. Another problem is that the export and import lists of the modules need to be generated too and this seems not an option for TH. Lars

On Dec 9, 2011 4:48 PM, "Stephen Tetley" wrote:

For the specific problem of OpenGL - as the package already exists I'm not sure a generative approach would actually pay its way

I strongly disagree. OpenGLRaw is in pretty bad shape right now. It's not up to date with the OpenGL spec and is very difficult to maintain. A generator is exactly what is needed. - Jake

On Sat, Dec 10, 2011 at 11:12 AM, Vo Minh Thu wrote:

2011/12/9 Stephen Tetley :

...

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.

On Fri, Dec 9, 2011 at 2:17 PM, Erik Hesselink wrote:

On Fri, Dec 9, 2011 at 20:45, L Corbijn wrote:

...

So I'm interested if there are other libraries that are more suitable to the task of generating haskell code for library use, and thus generate 'human readable' exported code (so no TH). I'm also interested in how other projects generate code for their packages.

Since you ask how other packages solve this problem, and since most packages use template haskell, I have to ask: why can't you use template haskell for this?

For my case, template haskell can't create modules, and template haskell solves a different problem - I've not interested in creating Haskell declarations from Haskell declarations - I'm interested in creating Haskell modules from an external, formal, specification. In a sense I'm compiling to Haskell.

Another option (also not code generation, but very useful in reducing boilerplate) is generic programming, for example using the 'regular' package, or the new generics in GHC 7.2.

Erik

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Fri, Dec 9, 2011 at 6:32 PM, Brandon Allbery wrote:

On Fri, Dec 9, 2011 at 17:27, Antoine Latter wrote:

...

On Fri, Dec 9, 2011 at 2:17 PM, Erik Hesselink wrote:

...

Since you ask how other packages solve this problem, and since most packages use template haskell, I have to ask: why can't you use template haskell for this?

For my case, template haskell can't create modules, and template haskell solves a different problem - I've not interested in creating Haskell declarations from Haskell declarations - I'm interested in creating Haskell modules from an external, formal,  specification. In a sense I'm compiling to Haskell.

It occurs to me that c2hs (or more appropriately the gtk2hsc2hs fork) is intended to solve this problem; have you looked into it?

That may be good for the opengl-raw, I was working on generating Haskell modules from an XML spec - I crashed the thread with my own (similar) problems :-)

-- brandon s allbery                                      allbery.b@gmail.com wandering unix systems administrator (available)     (412) 475-9364 vm/sms

On Fri, Dec 09, 2011 at 10:30:18PM +0100, L Corbijn wrote:

The major set of problems for using template haskell is that it doesn't have the correct features, or better said it tries to solve another problem. Template haskell generates code into an existing module, while for this problem there is no module yet to generate it into. Of course I could generate those modules and let template haskell make the FFI imports, but then the problem remains how to generate those modules. So template haskell seems (as I see it) to solve the problem of writing almost the same code twice by generating it from some parameters coded in some source file. Another problem is that the export and import lists of the modules need to be generated too and this seems not an option for TH.

On Fri, Dec 09, 2011 at 04:27:31PM -0600, Antoine Latter wrote:

For my case, template haskell can't create modules, and template haskell solves a different problem - I've not interested in creating Haskell declarations from Haskell declarations - I'm interested in creating Haskell modules from an external, formal, specification. In a sense I'm compiling to Haskell.

This answer is for both the above quotes. While TH is not perfect (and sometimes tedious/difficult to write in), it's not restricted to simply generate code based on some parameters in an existing Haskell file. It cannot generate modules, true, but other than that you could have a module simply like this: module Foo where import … $(myBuilder) Where myBuilder doesn't take any parameters, just reads some external (XML, text file, whatever) and build the code from scratch. I might misunderstand the problem, but I think that you _could_ use TH for "compiling" to Haskell, as long as you have a Haskell parser for the external/formal spec. regards, iustin

On Sat, Dec 10, 2011 at 1:59 PM, Geoffrey Mainland wrote:

On 12/10/2011 09:38, Iustin Pop wrote:

...

On Fri, Dec 09, 2011 at 10:30:18PM +0100, L Corbijn wrote:

...

The major set of problems for using template haskell is that it doesn't have the correct features, or better said it tries to solve another problem. Template haskell generates code into an existing module, while for this problem there is no module yet to generate it into. Of course I could generate those modules and let template haskell make the FFI imports, but then the problem remains how to generate those modules. So template haskell seems (as I see it) to solve the problem of writing almost the same code twice by generating it from some parameters coded in some source file. Another problem is that the export and import lists of the modules need to be generated too and this seems not an option for TH.

On Fri, Dec 09, 2011 at 04:27:31PM -0600, Antoine Latter wrote:

...

For my case, template haskell can't create modules, and template haskell solves a different problem - I've not interested in creating Haskell declarations from Haskell declarations - I'm interested in creating Haskell modules from an external, formal,  specification. In a sense I'm compiling to Haskell.

This answer is for both the above quotes. While TH is not perfect (and sometimes tedious/difficult to write in), it's not restricted to simply generate code based on some parameters in an existing Haskell file.

It cannot generate modules, true, but other than that you could have a module simply like this:

  module Foo where

  import …

  $(myBuilder)

Where myBuilder doesn't take any parameters, just reads some external (XML, text file, whatever) and build the code from scratch.

I might misunderstand the problem, but I think that you _could_ use TH for "compiling" to Haskell, as long as you have a Haskell parser for the external/formal spec.

regards, iustin

There are the haskell-src-exts-qq and haskell-src-meta packages on hackage that will get you partway to generating source code for a Haskell module. Full support for Haskell quasiquotation would require a modified version of haskell-src-exts (to properly handle antiquotation).

The problem with TH is that it runs when the module is compiled. Reading a spec in from a file within a TH quote is possible, but it would be much nicer to be able to write a code generator, which a full Haskell quasiquoter would allow.

Maybe someone is interested in a side-project? :)

Geoff

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

I hadn't really considered using quasi quotation for the generating part, but reading some things about it it seems to be nice use. In absence of quasi quotation I've, just as Antoine Latter, made a library of several helper functions to make code generating easier. Thank you for bringing quasi quotation to my attention.