Re: [Haskell-cafe] Learning GHC API
Hi, This sounds to me more like a job for haskell-src-exts [1]. Which represents full haskell source modules. The advantage above the GHC API is that it is more stable and does not require GHC at all. Lars [1]: http://hackage.haskell.org/package/haskell-src-exts-1.13.5 On Fri, Aug 2, 2013 at 2:07 PM, blackbox.dev.ml blackbox.dev...@gmail.comwrote: HI! Could you please give me hints where to find materials to learn GHC API? I know there is http://www.haskell.org/haskellwiki/GHC/As_a_library, but this contains only 2 examples and I would to learn how to create datatypes, classes, functions etc using GHC API, how to compile them later or generate Haskell code out of them (if its possible). I would be thnakful for any hint! :) Thank you, Wojtek ___ 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
[Haskell-cafe] Choosing an xml parser
Hello Cafe, I am trying to write a library to parse (and process) the OpenGL xml spec into haskell values. The problem is that I don't know what xml library to choose. So far I can think of the following requirements: - Some error reporting, possibly warning for unparsed elements (as that signals that the parser needs updating). - Not too bulky for the not so simple registry schema [1]. - Preferably some way to preprocess some nodes (this could probably be done by any xml library). - Preferably not too memory hungry (the current spec is about 2MB) Does somebody have a recommendation for a xml library to use for this? Regards, Lars [1]: https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/registry.rnc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] opengl type confusion
On Sun, Jun 16, 2013 at 10:42 PM, bri...@aracnet.com wrote: On Sun, 16 Jun 2013 16:15:25 -0400 Brandon Allbery allber...@gmail.com wrote: On Sun, Jun 16, 2013 at 4:03 PM, bri...@aracnet.com wrote: Changing the declaration to GLdouble - GLdouble - GLdouble - IO() and using (0.0::GLdouble) fixes it, and I'm not clear on why it's not automagic. There are many times I see the Haskell never automagics types in that context; if it expects GLdouble, it expects GLdouble. Pretending it's Double will not work. It would in the specific case that GLdouble were actually a type synonym for Double; however, for performance reasons it is not. Haskell Double is not directly usable from the C-based API used by OpenGL, so GLdouble is a type synonym for CDouble which is. compiler doing type conversion an numerican arguments although sometimes the occasional fracSomethingIntegralorOther is required. I presume the reason the type specification for numeric literals is because there is no defaulting (and probably can't be without introducing other strange type issues) for GLdouble. What I was thinking about, using a very poor choice of words, was this : *Main let a = 1 *Main :t a a :: Integer *Main let a = 1::Double *Main a 1.0 *Main :t a a :: Double *Main so normally 1 would be interpreted as an int, but if I declare 'a' a Double then it gets promoted to a Double without me having to call a conversion routine explicitly. That seems automagic to me. (0.0::GLdouble) works to make the compiler happy. So it appears to be taking care of the conversion automagically. So maybe a better question, I hope, is: How can I simply declare 0.0 to be (0.0::GLdouble) and have the functional call work. Doesn't a conversion have to be happening, i.e. shouldn't I really have to do (realToFrac 0.0) ? Brian ___ 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] opengl type confusion
I seem to making a mess of it, first accidentally posting an empty message
and then forgetting to reply to the list. Thirdly I forgot to mention that
my message only describes the 'GHCi magic'.
Lars
P.S. Conclusion, I shouldn't write complicated email this late on the
evening.
-- Forwarded message --
From: L Corbijn aspergesoe...@gmail.com
Date: Mon, Jun 17, 2013 at 12:07 AM
Subject: Re: [Haskell-cafe] opengl type confusion
To: bri...@aracnet.com
On Sun, Jun 16, 2013 at 11:10 PM, L Corbijn aspergesoe...@gmail.com wrote:
On Sun, Jun 16, 2013 at 10:42 PM, bri...@aracnet.com wrote:
On Sun, 16 Jun 2013 16:15:25 -0400
Brandon Allbery allber...@gmail.com wrote:
On Sun, Jun 16, 2013 at 4:03 PM, bri...@aracnet.com wrote:
Changing the declaration to GLdouble - GLdouble - GLdouble - IO()
and
using
(0.0::GLdouble) fixes it, and I'm not clear on why it's not automagic.
There are many times I see the
Haskell never automagics types in that context; if it expects
GLdouble,
it expects GLdouble. Pretending it's Double will not work. It would in
the specific case that GLdouble were actually a type synonym for Double;
however, for performance reasons it is not. Haskell Double is not
directly
usable from the C-based API used by OpenGL, so GLdouble is a type
synonym
for CDouble which is.
compiler doing type conversion an numerican arguments although sometimes
the occasional fracSomethingIntegralorOther is required.
I presume the reason the type specification for numeric literals is
because
there is no defaulting (and probably can't be without introducing other
strange type issues) for GLdouble.
What I was thinking about, using a very poor choice of words, was this :
*Main let a = 1
*Main :t a
a :: Integer
*Main let a = 1::Double
*Main a
1.0
*Main :t a
a :: Double
*Main
so normally 1 would be interpreted as an int, but if I declare 'a' a
Double then it gets promoted to a Double without me having to call a
conversion routine explicitly.
That seems automagic to me.
(0.0::GLdouble) works to make the compiler happy. So it appears to be
taking care of the conversion automagically.
So maybe a better question, I hope, is:
How can I simply declare 0.0 to be (0.0::GLdouble) and have the
functional call work. Doesn't a conversion have to be happening, i.e.
shouldn't I really have to do (realToFrac 0.0) ?
Brian
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Oops sorry for the empty reply, I accidentally hit the sent button.
What you are seeing is the defaulting (see
http://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-790004.3.4).
Which roughly speaking means that if you need a specific instance of a
number first try Integer then Double and as a last resort fail.
Prelude :t 1
1 :: Num a = a
Prelude :t 1.0
1.0 :: Fractional a = a
So normally a number can be just any instance of the Num class, and any
number with a decimal can be any Fractional instance. And now with let
bindings
The need for defaulting is caused by the monomorphism restriction (
http://www.haskell.org/haskellwiki/Monomorphism_restriction), which states
that let binds should be monomorphic, or roughly speaking it should contain
no type variables (unless of course you provide a type signature).
Prelude let b = 1
Prelude :t b
b :: Integer
Prelude let c = 1.0
Prelude :t c
c :: Double
So here you see the result of the combination. The monomorphism restriction
doesn't allow 'Num a = a' as type for 'b'. So the defaulting kicks in and
finds that its first guess 'Integer' fits. Therefore 'b' gets type
Integer. Though for 'c' the guess 'Integer' fails as it isn't a Fractional.
Its second guess, Double, is a fractional so 'c' gets type Double.
You can see that the monomorphism restriction is to blame by disabling it
Prelude :set -XNoMonomorphismRestriction
Prelude let b = 1
Prelude :t b
b :: Num a = a
But you shouldn't normally need to do this, as you can provide a specific
type signature.
(in a fresh GHCi session)
Prelude let {b :: Num a = a; b = 1}
Prelude :t b
b :: Num a = a
On Sun, Jun 16, 2013 at 10:42 PM, bri...@aracnet.com wrote:
On Sun, 16 Jun 2013 16:15:25 -0400
Brandon Allbery allber...@gmail.com wrote:
On Sun, Jun 16, 2013 at 4:03 PM, bri...@aracnet.com wrote:
Changing the declaration to GLdouble - GLdouble - GLdouble - IO()
and
using
(0.0::GLdouble) fixes it, and I'm not clear on why it's not automagic.
There are many times I see the
Haskell never automagics types in that context; if it expects GLdouble,
it expects GLdouble. Pretending it's Double will not work. It would in
the specific case that GLdouble were actually a type synonym for Double;
however, for performance reasons it is not. Haskell Double is not
directly
usable from the C-based API used by OpenGL, so GLdouble
Re: [Haskell-cafe] Yampa integral function
Warning: no knowledge of Yampa. It seems that the integration for the position is always using the velocity from the previous step. Looking at the documentation in source code of Yampa this seems plausible as there is also a function called imIntegrate with the comment -- immediate integration (using the function's value at the current time) Which I assume would yield your answer. As I don't know Yampa I can only speculate about the reason for this difference, the two things I can think of now are better speed and to prevent trouble (in cases like x = integral y, y = integral x). Lars On Wed, Apr 17, 2013 at 1:55 AM, Jerzy Karczmarczuk jerzy.karczmarc...@unicaen.fr wrote: Le 17/04/2013 01:48, Jerzy Karczmarczuk a écrit : With constant acceleration v=v0+a*Dt = 1.01, not 1.05 Gosh, trivial errors seem to be contagious. Of course I meant 1.1, not 1.01. Sorry. JK __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://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] ANNOUNCE: antiquoter-0.1.0.0
Hi, A late reply, I was a bit busy. My comments are inline On Thu, Apr 4, 2013 at 7:30 PM, Tillmann Rendel ren...@informatik.uni-marburg.de wrote: Hi, L Corbijn wrote: I'm happy to announce the release of my first package antiquoter, a combinator library for writing quasiquoters and antiquoters. The main aim is to simplify their definitions and reduce copy-and-paste programming. Very interesting. I'm using something similar to your EP class, but yours looks more refined. See class PatOrExp in https://github.com/Toxaris/pts/blob/master/src-lib/PTS/QuasiQuote.hs That looks interesting. Maybe I should include your version of Lift, to extend the version of template-haskell to also work on patterns. I'm a bit overwhelmed by the rest of your library, though. Is the overall design explained somewhere? It isn't really explained somewhere, so I should update the documentation with it. The basic idea is that you build an AntiQuoter out of separate AntiQuoterPass-es using () or (). The resulting AntiQuoter can then be used by dataToExpQ/dataToPatQ to form the total QuasiQuote, or using the helper function mkQuasiQuoter. The pattern-expression similarity is build is build on top of this abstraction, where the result of the AntiQuoter(Pass) is fixed to any instance of the EP class. Which are then used to define quite a few combinators. Anyway, I'll try to update the documentation soon to make the design a bit clearer. And: Your package description says that it is especially aimed at making user extensible antiquoters. That sounds very cool. Can you provide an example for how the antiquoter package supports extensions, and what kinds of extensions are supported? That aim should have been removed as it still is not done. But let me put it into context. The package started of as some reusable parts which I got from refactoring haskell-src-exts-qq. Its quasiquoter has three patterns to get something antiquoted each with their own special use cases. The problem was that I wanted something antiquoted which could not be done in one of those three patterns. Adding a fourth pattern has its problems, so I started antiquoter with one of the aims being to make antiquoters extensible by the user. I think I have got some ideas of how to do this, but I didn't find the time to add them. Lars Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: antiquoter-0.1.0.0
Hello cafe, I'm happy to announce the release of my first package antiquoter [1], a combinator library for writing quasiquoters and antiquoters. The main aim is to simplify their definitions and reduce copy-and-paste programming. The main feature the current version is trying to solve is code duplication in antiquoters. The problem for writing antiquoters is that it need to be done twice, once for use as an expression and once for use as a pattern. These two implementations are very similar, which leads to copy-and-paste programming. For a good example of what this leads to see the antiquoters of language-c-quote[2], where almost every antiquoter is written twice. A very simple example with the rewritten version is provided in the documentation [3]. Lars [1]:http://hackage.haskell.org/package/antiquoter [2]: http://hackage.haskell.org/packages/archive/language-c-quote/0.7.1/doc/html/src/Language-C-Quote-Base.html [3]: http://hackage.haskell.org/packages/archive/antiquoter/0.1.0.0/doc/html/Language-Haskell-AntiQuoter-ExpPat.html [4]:https://github.com/Laar/antiquoter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Building pattern and trying monads
Hello cafe, I'm working on a project where the main goal of the program is building some complex output (e.g. a Haskell function, module, etc.). In this process there is almost always some partially finished product on which to work. Currently I'm modelling this with a wrapper around StateT containing the partial product but I'm having some doubts about this approach. On one of the projects there is some rule-based transformation which needs to be done. The problem is with the matching and applying the rules. The matches need to retrieve information from the monads in the stack, and the application of a rule changes values in the stack. However when a match fails the stack should be left *untouched* and another rule should be tried. The solution I've in mind depends on the stack being pure. When the monad stack is pure a rule can be applied, returning a maybe value (or having a MaybeT wrapper) and when returning Nothing (failed rule) reverting the stack to it's point before applying the rule. As I'm not quite sure about the design (nor good at software design) I've some questions about this approach. 1. Is there a better approach then using a state monad for building the 'products'? 2. My solution with saving/reverting monad-stacks seems quite a hassle/hack, so is it a good approach or is there something better? Thanks in advance, Lars ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OpenGL: No instance for Random GLfloat
Hi,
GLfloat haskell is instance of several number related typeclasses. A
function like 'fromRational' could be used to create a GLfloat from another
number that has a random instance.
L
On May 3, 2012 4:39 AM, Mark Spezzano mark.spezz...@chariot.net.au
wrote:
Hi,
I tried this but now I get another error:
The data constructors of `GLfloat' are not all in scope
so you cannot derive an instance for it
In the stand-alone deriving instance for `Random GLfloat'
Mark
On 03/05/2012, at 10:39 AM, Patrick Palka wrote:
Because GLfloat is simply a newtype wrapper for CFloat, which has a Random
instance, I would do:
{-# LANGUAGE StandaloneDeriving #-}
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
deriving instance Random GLFloat
On Wed, May 2, 2012 at 6:29 PM, Mark Spezzano
mark.spezz...@chariot.net.au wrote:
Hi Haskellers,
I'm trying to generate a random vertex in OpenGL as follows.
genPosition :: IO (Vertex3 GLfloat)
genPosition = do x - getStdRandom $ randomR (-1.6,1.6)
y - getStdRandom $ randomR (-1.0,1.0)
return (Vertex3 x y (-1))
Unfortunately the compiler complains about me having to implement an
instance of Random for GLfloat.
How do I do this (or avoid having to do this)?
Cheers,
Mark
___
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
___
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] Un-memoization
On Mar 22, 2012 2:56 AM, Victor Miller victorsmil...@gmail.com wrote: I was writing a Haskell program which builds a large labeled binary tree and then does some processing of it, which is fold-like. In the actual application that I have in mind the tree will be *huge*. If the whole tree is kept in memory it would probably take up 100's of gigabytes. Because of the pattern of processing the tree, it occurred to me that it might be better (cause much less paging) if some large subtrees could be replaced by thunks which can either recalculate the subtree as needed, This sounds like weak references (warning this is tricky stuff), http://www.haskell.org/ghc/docs/7.0.2/html/libraries/base-4.3.1.0/System-Mem-Weak.html or write out the subtree, get rid of the references to it (so it can be garbage collected) and then read back in (perhaps in pieces) as needed. This could be fairly cleanly expressed monadically. So does anyone know if someone has created something like this? Victor ___ 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] Loading a texture in OpenGL
On Tue, Feb 7, 2012 at 5:23 AM, Austin Seipp mad@gmail.com wrote: Just to clarify, this guarantee possibly could be made, ghc just doesn't do it now. In the past ghc never guaranteed a finalizer would ever be run. Regardless I would be wary of trusting finalizers to clean up very scarce resources. A malloc'd buffer is probably fine to have a finalizer for, texture objects or file descriptors are a different matter. Predictability matters in those cases. Sent from my iPhone^H^H^H^H^HPortable Turing machine On Feb 6, 2012, at 10:16 PM, Austin Seipp mad@gmail.com wrote: It's a precise GC of course (conservative collection would be madness considering how much memory Haskell programs chew through.) That still doesn't ensure your finalizer will run during the next GC even if all the references are gone by then. Sent from my iPhone^H^H^H^H^HPortable Turing machine On Feb 6, 2012, at 10:09 PM, Clark Gaebel cgae...@csclub.uwaterloo.ca wrote: Is the Haskell garbage collector conservative, or precise? If it's conservative, then this will only usually work. If it's precise, it should always work. On Mon, Feb 6, 2012 at 10:56 PM, Ben Lippmeier b...@ouroborus.net wrote: On 07/02/2012, at 2:50 PM, Clark Gaebel wrote: I would be running the GC manually at key points to make sure it gets cleaned up. Mainly, before any scene changes when basically everything gets thrown out anyways. From the docs: newForeignPtr :: FinalizerPtr a - Ptr a - IO (ForeignPtr a)Source Turns a plain memory reference into a foreign pointer, and associates a finalizer with the reference. The finalizer will be executed after the last reference to the foreign object is dropped. There is no guarantee of promptness, however the finalizer will be executed before the program exits. No guarantee of promptness. Even if the GC knows your pointer is unreachable, it might choose not to call the finaliser. I think people have been bitten by this before. Ben. ___ 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 You have to be really careful with automatic cleanup using finalizers. Not only to the mentioned not cleaning up of resources but also to deleting it too early. What could happen is that you code doesn't explicitly use (= call a GL function with it) an object after binding it. Then it could be seen as a dead pointer and be deleted by it's finalizer. But thereby it might unbind the object from the binding point. Maybe a (more) realistic example is using only one shader program, you create it once, call usePorgram with it and never change it after that. As there is no other program to use you don't have to reactivate the program with useProgram or have to change anything about it. So in effect it's not used by Haskell anymore and the finalizer is run for it deleting the program. For a program this is not a big problem as the OpenGL spec tells you that it isn't deleted immediately so you can use it afterwards. With textures it's different, the are deleted immediately, so you may think you have a texture bound but in reality the finalizer might have run and deleted the texture for you. So watch doing the OpenGL memory management using the references in Haskell, as you might accidentally delete objects ahead of time. Lars, P.S. To make it worse, the bound objects (programs, textures, etc.) can also be queried and thereby there are non dead objects automatically, but there is no Haskell reference to them so the GC cannot now this. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fwd: Rewrite this imperative in FP way
-- Forwarded message -- From: L Corbijn aspergesoe...@gmail.com Date: Sun, Feb 5, 2012 at 10:07 AM Subject: Re: [Haskell-cafe] Rewrite this imperative in FP way To: Haisheng Wu fre...@gmail.com On Sun, Feb 5, 2012 at 7:28 AM, Haisheng Wu fre...@gmail.com wrote: a = [1,1,1,1] b = [0,1,2,3] d = [0,0,0,0] for i in b: for j in c: if (i+j)3: d[i+j] += a[i] My just work implementation in Haskell http://hpaste.org/57452 Another people implementation in Haskell with Monad and it turns out complex and very imperatively. http://hpaste.org/57358 Do you have any cool solution in FP way? Thanks. -Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Oops forgot to reply to the list, There are several ways to make it nicer. Without assumption on what lists a, b and c contain it can be written as d = [sum $ map (a !!) [i | i - b, j - c, i + j 3, i + j == dIndex] | dIndex - [0..3]] With the assumption that b and c are both [0..3] this can be 'improved' to d = (take 3 . map sum . tail $ inits a) ++ replicate (4 - 3) 0 This generates the first three values by the complicated expression and then adds the extra zero's by using the replicate expression. This works as the value of the i-th element of d is the sum over the first i elements in a if i 3 and 0 otherwise. A list of lists with the first i elements is generated with 'tail $ inits a' which is then summed and restricted to length 3. An alternative for this is d = (take 3 . snd $ mapAccumL (\acc ai - (acc + ai, acc + ai)) 0 a) ++ replicate (4 - 3) 0 Where the summation and tail generating is done in the mapAccumL function. Greetings, Lars P.S. Yes the replicate (4-3) 0 can be replaced by [0], but I wanted to explicitly include the length (4) of the expected list. P.P.S. for those of you wondering what c is, looking at the solutions in hpaste c is probably defined as c = [0..3]. ___ 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
[Haskell-cafe] Generating Code
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. Greetings, Lars Corbijn ___ 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] OpenGL vs OpenGLRaw
On Sat, Jul 23, 2011 at 8:51 PM, Yves Parès limestr...@gmail.com wrote: Hello Café, Where do you people stand on using OpenGLRaw instead of the higher-level layer? I saw that the ports of the nehe tutorial use directly OpenGLRaw, and I wondered why that choice had been made. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Hi, I was/am working on improving the OpenGL package. My view on things is that the Raw package is a pure ffi package that imports the C functions for use in haskell. The OpenGL package tries to make a more type safe interface on top of the Raw package. I think that the nehe tutorials are more easily and readable ported to the raw package (as it's using the raw C). The following is my viewpoint on the current packages, Some reasons for using the Raw package might be - more constant API, it's the raw C api, while the OpenGL package sometimes changes due to adding functionality. - functionality is supported earlier in the Raw package. Some reasons for using the OpenGL package - Better type safety (can't mismatch a Shader and program identifier) - Utility and typeclass (overloaded) functions The biggest disadvantage of the OpenGL package is that it is a bit outdated from the viewpoint of OpenGL functions, I was/am trying to add support for 3.0 and later. Hopefully the package OpenGL will improve over time to include functions for the newer OpenGL API versions. One other option, though not the nicest from somepoints, is using both. The idea is to use where ever possible the functions of the OpenGL package, and where necessary unsafeCoerce the object to the Identifier used by OpenGL and use that for the Raw function. This works because all (as far as I know) the OpenGL objects are represented by newtypes. Hopefully the number of functions where this is needed will be reduced in the near future, as there are quite some points where they are needed (Mostly for OpenGL = 3.0). Lars Corbijn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Inconsistent trailing comma in export list and record syntax
Hello,
I'm wondering why the trailing comma is allowed in export syntax, but not in
record syntax, here an example
module Foo (
export1, -- is allowed
) where
data Type = Type {
record1 :: Foo, -- is not allowed
}
To me this seems quite inconsistent and sometimes quite frustrating, imagine
the case that you want to temporarily remove the last record:
data Type = Type {
record1 :: Foo,
--record2 :: Bar
}
this would fail due to an extra comma that has to be commented out.
You could of course say that I'm using a bad style, but it remains that it
seems to be inconsistent to allow a trailing comma in one place and not in
the other. So is there an reason for this?
Lars Corbijn
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
