Re: [Haskell-cafe] Generating Code
It occurs to me that c2hs (or more appropriately the gtk2hsc2hs fork) is intended to solve this problem; have you looked into it? hdirect falls into this category as well ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Generating Code
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Generating Code
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
Re: [Haskell-cafe] Generating Code
On 12/09/2011 21:47, Stephen Tetley wrote: 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. In case anybody is interested, language-c-quote on hackage is the current version of the C quasiquoting library from the workshop paper. Geoff For the specific problem of OpenGL - as the package already exists I'm not sure a generative approach would actually pay its way ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Generating Code
On Sat, Dec 10, 2011 at 11:12 AM, Vo Minh Thu not...@gmail.com wrote: 2011/12/9 Stephen Tetley stephen.tet...@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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Generating Code
On Sat, Dec 10, 2011 at 1:59 PM, Geoffrey Mainland mainl...@apeiron.net 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Generating Code
On Fri, Dec 9, 2011 at 1:45 PM, L Corbijn aspergesoe...@gmail.com wrote: Hello, In an attempt to reduce the amount of boring repetitive work to update the OpenGLRaw package I've created a generator to do it partially for me. It currently uses haskell-src-exts for representing the haskell source of the modules. Though haskell-src-exts does an excellent job for representing haskell source, it seems to be more aimed at parsing haskell source and doing something with it, rather than generating it. For cpp macros, say for the use of different calling conventions used, can't be used directly, nor is there a really good way to use comments (at least so it seems to me). 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. I've used 'haskell-src' to generate code, but thankfully I didn't need to include any CPP. I've wanted to experiment with using haskell-src-exts to generate code with Haddocks, but it looks like it will be painful, since it doesn't include comments in the syntax tree proper. This is appropriate for arbitrary comments, but Haddocks can only appear in specific locations (I think?). Here is a utility module I use as a wrapper around haskell-src to make it a bit friendlier for generating modules: http://code.haskell.org/~aslatter/code/xhb/build-utils/src/HaskellCombinators.hs Maybe you can add an 'OtherCall String' calling convention to haskell-src-exts? I'm not sure what to do about comments. Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Generating Code
On Fri, Dec 9, 2011 at 20:45, L Corbijn aspergesoe...@gmail.com 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Generating Code
On Fri, Dec 9, 2011 at 9:17 PM, Erik Hesselink hessel...@gmail.com wrote: On Fri, Dec 9, 2011 at 20:45, L Corbijn aspergesoe...@gmail.com 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Generating Code
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Generating Code
On Fri, Dec 9, 2011 at 2:17 PM, Erik Hesselink hessel...@gmail.com wrote: On Fri, Dec 9, 2011 at 20:45, L Corbijn aspergesoe...@gmail.com 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Generating Code
On Dec 9, 2011 4:48 PM, Stephen Tetley stephen.tet...@gmail.com 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Generating Code
On Fri, Dec 9, 2011 at 17:27, Antoine Latter aslat...@gmail.com wrote: On Fri, Dec 9, 2011 at 2:17 PM, Erik Hesselink hessel...@gmail.com 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? -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Generating Code
On Fri, Dec 9, 2011 at 6:32 PM, Brandon Allbery allber...@gmail.com wrote: On Fri, Dec 9, 2011 at 17:27, Antoine Latter aslat...@gmail.com wrote: On Fri, Dec 9, 2011 at 2:17 PM, Erik Hesselink hessel...@gmail.com 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 allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
