If you say {-# INLINE f #-} on a fn defn for f, it'll get inlined at all its call sites, which is sort of what you want. Just saying 'evaluate this CAF to WHNF' might only inline the outer combinator. Generally, some precise way of controlling what gets evaluated at compile time, a bit less heavyweight than MetaML, would be a fine thing. After all that's what C++ templates are. But the details of a workable design aren't clear to me. Ideas? Simon | -----Original Message----- | From: David Feuer [mailto:David_Feuer@brown.edu] | Sent: 01 February 2002 07:41 | To: glasgow-haskell-users@haskell.org | Subject: partial evaluation | Sensitivity: Confidential | | | It seems to me that it might be useful (and probably | fairly easy) to add to GHC a limited sort of partial | evaluation: programmer-designated top-level CAFs could be | evaluated to WHNF during compilation. Termination of that | compiler phase would obviously not be guaranteed, but if | this were possible, I am guessing it would be very useful | for some applications, such as combinator-based parsers. | The parsers would then be generated at compiler time | rather than re-generated every time the parser is | executed. If GHC in fact supports something of this | nature, I would love to hear about it. If it does not, I | would guess it would probably be fairly easy to add to the | end of the code generation phase. | | David Feuer | | This message has been brought to you by the letter alpha and | the number pi. | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |
On Mon, 4 Feb 2002, Simon Peyton-Jones wrote:
If you say {-# INLINE f #-} on a fn defn for f, it'll get inlined at all its call sites, which is sort of what you want. Just saying 'evaluate this CAF to WHNF' might only inline the outer combinator.
Generally, some precise way of controlling what gets evaluated at compile time, a bit less heavyweight than MetaML, would be a fine thing. After all that's what C++ templates are.
But the details of a workable design aren't clear to me. Ideas?
This is from a rank amateur, so take it with a pinch of salt... It would be useful to see typical examples of CAFs for which this would be expected to be useful. In my (limited) programming I haven't come across that many, with the dominant example being `symbol table' type things, for which I've generally had a script write out a Haskell module containing the defs. Other than being slightly more work, the only hassle is that it forces an otherwise unecessary Show into the type. What other examples are there where normal evaluation at compile time would be useful? As far as I know the principal advantage of templates functions in C++ (which I think you're talking about) is that they can be seen as generating further code (probably in the form of abstract syntax tree nodes) which is then exposed to the usual _compiler_ optimizations (abstract evaluation and rewriting is I guess the formal terms) such as hoisting loop invariants, collapsing addressing arithmetic, etc. It's not totally clear to me that analogous Haskell stuff can be done using `standard Haskell evaluation' as opposed to compiler optimizations. ___cheers,_dave_________________________________________________________ www.cs.bris.ac.uk/~tweed/|`...heat generated by its microprocessors will email:tweed@cs.bris.ac.uk|slope upward exponentially, reaching the power work tel:(0117) 954-5250 |density of a nuclear reactor before 2010'-Intel
participants (2)
-
D. Tweed -
Simon Peyton-Jones