Hi Simon,
For all I know, no one is using quasi-quotation (although it's a very
cool feature, thanks to Geoff Mainland), but I didn't think I should
take it for granted!
For info, My PhD student George Giorgidze and myself are using it
for our EDSL Hydra for non-causal modelling and
(ii) If [pads| is a lexeme, then some list comprehensions become
illegal,
I am not myself a TH or QQ user, but it has always bothered me
slightly that the syntax for them steals some valid list comprehensions.
Of the alternative syntaxes you suggest...
My gut feel is to go with [|pads|
Perhaps rtsSupportsBoundThreads can help:
http://www.haskell.org/ghc/docs/6.12.1/html/libraries/base-4.2.0.0/Control-Concurrent.html#v%3ArtsSupportsBoundThreads
Best regards
Krzysztof Skrzętnicki
On Mon, Feb 1, 2010 at 06:33, John Lask jvl...@hotmail.com wrote:
Hello
I hope someone can
Hi,
I've been experimenting with quasiquoting, and would like to see both of
Kathleen's suggestions adopted. The top level quasi quotes would be useful,
and reducing the notational noise would be very nice. I don't see the issue of
stealing some currently-valid list comprehensions as very
On 29/01/2010 21:02, Tyson Whitehead wrote:
I was looking through the code for 6.12.1 and am a bit confused about 11.1.3
in the runtime system documentation docs/rts/rts.tex.
That's a very old document and is inaccurate in various ways. The
Commentary is more up to date:
I've created a ticket for this:
http://hackage.haskell.org/trac/ghc/ticket/3852
Cheers,
Simon
On 31/01/2010 13:28, Nicolas Martyanoff wrote:
Hi,
By reading Matthias Kilian's scripts (thank you !), I successfully builded GHC
6.12.1.
GHC 6.10.4 didn't build:
gLexer.x
On February 1, 2010 06:43:40 Simon Marlow wrote:
That's a very old document and is inaccurate in various ways. The
Commentary is more up to date:
http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts
That's good to know. Thanks for the link. : )
Cheers! -Tyson
signature.asc
Hello,
For all I know, no one is using quasi-
quotation (although it's a very cool feature, thanks to Geoff
Mainland), but I didn't think I should take it for granted!
As a point of reference, we are using quasi-quotation extensively in our
machinery for generating Javascript, which we also
I like (1) quite a lot. If radical suggestions for QQ noise reduction
are being entertained, here's another:
quotations of the form [| |] (i.e. no 'language' specified) will
use an implicit parameter* ('quasi', say) of type QuasiQuoter, if in
scope. Otherwise, they will behave as they
| quotations of the form [| |] (i.e. no 'language' specified) will
| use an implicit parameter* ('quasi', say) of type QuasiQuoter, if in
| scope. Otherwise, they will behave as they currently do (TH
| expression quotation?). Now to awaken the 'pads' magic (or some other
| magic), you'd do
Hi all,
Simon wrote (answering Robert Greayer):
A variant of your suggestion would be: for any quote [|..blah..|]
behave as if the programmer had written [quasiQuoter| ...blah...|].
That is, simply pick up whatever record named quasiQuoter is in
scope. Then you'd say
import Pads(
A variant of your suggestion would be: for any quote [|..blah..|] behave as
if the programmer had written [quasiQuoter| ...blah...|]. That is, simply
pick up whatever record named quasiQuoter is in scope. Then you'd say
import Pads( quasiQuoter )
and away you go. But you can only
2010/02/01 Simon Peyton-Jones simo...@microsoft.com:
That might be quite convenient, but alas [|...|] has already
been taken by Template Haskell quotes, meaning [e| ...|]. So
you'd need something else. [*|...|] perhaps.
Why is that a problem? Would TH and quasi-quoting be likely to
be
13 matches
Mail list logo
