Re: Quasi quoting
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 simulation of physical systems. Indeed, it is a very cool feature. Actually, for us, almost essential, as it gives us *principled* control over the syntax of the deep aspects of our embedding in a way that the usually embedding tricks just don't provide. We'll have a look. Thanks for letting us know! /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Quasi quoting
(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| ... |]. ... this one feels the nicest, because [| |] is an ascii approximation of the common syntactic brackets used in semantic specifications. In some ways, to make the correspondence even closer, pads [| ... |] might be even better, although I realise that this might present new problems. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc rts selection and third party libraries
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 provide some guidance on how I can solve a certain problem. I have a library that taps into the ghc c rts: specifically when the rts is single threaded I am pumping events in via: stg_pending_events, when the threaded rts is used I use sendIOManagerEvent. i.e. I have two versions of the library with the same api. The problem with this is that either library is only good for one context: either threaded rts or not, and the user needs to select the appropriate library to use depending on the use context. What I want to be able to do is to have ghc automatically select the compiled library version to link in depending on the which rts option is selected: -thread or not does any one have any ideas? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Quasi quoting
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 serious. Since
[t|t-ts] and other forms are gone, I've come to think of the syntax [foobar|
as already taken for all foobar.
The loss here seems minimal but the gain is that DSLs can look more natural.
John O'Donnell
-Original Message-
From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Simon
Peyton-Jones
Sent: 01 February 2010 06:51
To: glasgow-haskell-users@haskell.org
Cc: Kathleen Fisher; mainl...@eecs.harvard.edu
Subject: Quasi quoting
Dear GHC users
This email is to announce two proposed changes to GHC's quasi-quotation
mechanism. 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!
The current spec is here:
http://haskell.org/haskellwiki/Quasiquotation
http://www.haskell.org/ghc/docs/latest/html/users_guide/template-haskell.html#th-quasiquotation
A quasi-quote can appear as a (a) expression (b) pattern, and looks like this
[$pads| ...blah... |]
where 'pads' (of course any name will do) is a record of functions
data QuasiQuoter = QuasiQuoter {
quoteExp :: String - Q Exp
quotePat :: String - Q Pat
}
The idea is that GHC evaluates (pads ...blah...), and splices in the
resulting Exp (or Pat) just as if that's what the user wrote in the first place.
Kathleen Fisher has started to use this for her PADS system, and came up with
two suggestions.
1. Allow quasi-quotes at the (top-level) declaration level, just like TH
splices. So you could say, at top level
[$pads| ...blah... |]
and have it expand to a bunch of top level Haskell declarations. This seems
like an unconditionally good idea. To support it we'd need to add a field to
QuasiQuoter:
data QuasiQuoter = QuasiQuoter {
quoteExp :: String - Q Exp
quotePat :: String - Q Pat
quoteDec :: String - Q [Dec]
}
but I don't think anyone will lose sleep over that.
2. Make the notation less noisy for the customer. In particular, that '$'
is scary, and redundant to boot. She would like to write
[pads| ...blah... |]
I can see the motivation here, but there are two reasons for caution.
(i) The Template Haskell quote forms [t| ... |] and [d| ... |] behave
rather differently.
(ii) If [pads| is a lexeme, then some list comprehensions become illegal,
such
as [x|x-xs,y-ys]. But note that because of Template Haskell
quotations,
a comprehension [t|t-ts] is already broken, and similarly with 'd', 'e'.
So the proposed change will make things *more* uniform, by grabbing every
[blah| as lexeme.
For me (i) is the main issue. The differences are significant.
- A TH quote can appear only where an *expression* is expected
But a quasiquote can be an expression or pattern or (assuming (1))
declaration
- A TH quote has type (Q Typ) or (Q [Dec]) or (Q Exp)
But a quasiquote is run immediately and spliced in place of the quote
- A TH splice is run during type checking
But a quasiquote is run during renaming
Even given all that, I'm strongly inclined to follow Kathleen's suggestion:
- The differences are there all right, but in some ways the programmer thinks
the same way: [lang| blah |] switches to language 'lang'.
- Many users will never encounter the issue; they'll just say
[pads| blah |]
to wake up the PADS magic, and be oblivious to Template Haskell quotes
An alternative would be to have some other cue. Ones I've considered
- $[pads| ...|], but allowing the $ to be omitted on top-level declarations,
top level, just as it now can for TH splices.
- [pads:| ... |], with the colon distinguishing quasi-quoting from TH.
My gut feel is to go with [|pads| ... |]. Of course this'd be a change from
the current syntax, but I think there are few enough users that they'll switch
easily enough.
Any comments on any of this?
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
The University of Glasgow, charity number SC004401
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Question regarding combinator call convention
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: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts It says the arguments passing convention to a known combinator differs from that of the others in that it starts the arguments with R1 instead of R2 (R1 points to the associated memory data structure for non-combinators). The address of the closure is always passed in R1, and the arguments start at R2, if R2 is a register, or the stack otherwise. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: building 6.12.1 with itself
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 gmake[2]: g: Command not found gmake[2]: [Lexer.hs] Error 127 (ignored) RTS -K2m -RTS -agc --strictParser.y gmake[2]: RTS: Command not found gmake[2]: *** [Parser.hs] Error 127 Failed making boot in genprimopcode: 1 gmake[1]: *** [boot] Error 1 gmake: *** [stage1] Error 1 But GHC 6.8.3 did. I then built GHC 6.12.1. The only problem was that the build process doesn't find the iconv lib when it's installed in /usr/local, so the lib/include paths have to be specified when running ./configure. I then installed Cabal 1.9 from darcs, and cabal-install, still from darcs. I used cabal to install hscolour, xmonad and xmonad-contrib, it worked perfectly. I thought it might be good to build GHC 6.12.1 with itself just to be sure it's working fine before make a dist, but I now get the following error: /usr/local/bin/ghc -H32m -O -package-conf libraries/bootstrapping.conf -package-name ghc-6.12.1 -hide-all-packages -i -icompiler/nativeGen -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/cprAnalysis -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/main -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage1/build -icompiler/stage1/build/autogen -Icompiler/stage1/build -Icompiler/stage1/build/autogen -Icompiler/stage1 -Icompiler/../libraries/base/cbits -Icompiler/../libraries/base/include -Icompiler/. -Icompiler/parser -Icompiler/utils-optP-include -optPcompiler/stage1/build/autogen/cabal_macros.h -package Cabal-1.9.0 -package array-0.3.0.0 -package base-4.2.0.0 -package bin-package-db- 0.0.0.0 -package bytestring-0.9.1.5 -package containers-0.3.0.0 -package directory-1.0.1.0 -package filepath-1.1.0.3 -package hpc-0.5.0.4 -package old-time-1.0.0.3 -package process-1.0.1.2 -package unix-2.4.0.0 -DSTAGE=1 -Wall -fno-warn-name-shadowing -fno-warn-orphans -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -XRelaxedPolyRec -odir compiler/stage1/build -hidir compiler/stage1/build -stubdir compiler/stage1/build -hisuf hi -osuf o -hcsuf hc -c compiler/main/Packages.lhs -o compiler/stage1/build/Packages.o compiler/main/Packages.lhs:233:63: Couldn't match expected type `InstalledPackageInfo_ String' against inferred type `Cabal-1.8.0.2:Distribution.InstalledPackageInfo.InstalledPackageInfo_ m' Expected type: [InstalledPackageInfo_ String] Inferred type: [Cabal-1.8.0.2:Distribution.InstalledPackageInfo.InstalledPackageInfo_ m] In the second argument of `map', namely `conf' In the first argument of `return', namely `(map installedPackageInfoToPackageConfig conf)' gmake[1]: *** [compiler/stage1/build/Packages.o] Error 1 gmake: *** [all] Error 2 I tried to ghc-pkg mask Cabal-1.8.0.2, then Cabal-1.9.0, didn't change anything. Does someone know what's going on here, and what can be done to fix it ? Regards, ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Question regarding combinator call convention
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 Description: This is a digitally signed message part. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Quasi quoting
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 put on Hackage as the jmacro package. A small syntax change probably wouldn't be a big deal for us. We'll think about the other proposed changes some more and offer some comments if we have anything interesting to say. thanks for the warning, Jeff --- This communication may contain confidential and/or privileged information. If you are not the intended recipient (or have received this communication in error) please notify the sender immediately and destroy this communication. Any unauthorized copying, disclosure or distribution of the material in this communication is strictly forbidden. Deutsche Bank does not render legal or tax advice, and the information contained in this communication should not be regarded as such.___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Quasi quoting
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 currently do (TH
expression quotation?). Now to awaken the 'pads' magic (or some other
magic), you'd do this somewhere:
quasi = pads
and then all your [| |]'s would be pads expressions/patterns/declarations.
Rob
* - implicit parameters fill me with a nameless dread under normal
circumstances.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Quasi quoting
| 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 this somewhere:
|
| quasi = pads
Nice idea, but won't work as specified. The thing is that the quasiquoter is
run at *compile time*. So it can't be an implicit parameter, which is by
definition only available at runtime
f :: (?q:QuasiQuoter) = ..blah...
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 use one at a time.
That might be quite convenient, but alas [|...|] has already been taken by
Template Haskell quotes, meaning [e| ...|]. So you'd need something else.
[*|...|] perhaps.
Or we could switch to different quotation brackets altogether for
quasiquotation, the obvious possibility being |...blah...|, and
pads|...blah...|. That would not be hard, and would only affect the handful
of current quasiquote users. But it'd remove | and | as a valid
operators, at least for quasiquote customers. I don't know how bad that would
be.
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Quasi quoting
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( quasiQuoter ) and away you go. But you can only use one at a time. Yes, I can see that (or one of the alternative forms proposed) would sometimes be convenient. But, being explicit about *which* syntax one is switching into does arguably enhance readability. Without this cue, the reader have to hunt for the appropriate binding before he or she can make sense of a piece of quasiquoted text. Also, as Simon suggests, being explicit makes it possible to use more than one quasiquoter at a time (in one module). Potentially quite useful. I can see being explicit about which quasiquoterbeing to use would be a bit of an issue in a setting with lots of very small fragments being spliced in all over the place. But at least in our experience, and what we've seen in Geoffrey's papers, quiasiquoted code fragments tend to be relatively substantial, where naming the quasiquoter doesn't add much overhead at all. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Quasi quoting
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 use one at a time. That might be quite convenient, but alas [|...|] has already been taken by Template Haskell quotes, meaning [e| ...|]. So you'd need something else. [*|...|] perhaps. Would it be possible to have [| ... |] mean [quasiQuoter| ... |] iff a 'quasiQuoter' has been imported, but otherwise mean [e| ... |]? Or does the determination to treat [something| .. blah .. |] as a quasi quote need to be made before it is possible to determine if there really is a 'something' available to process the quasi quote? You could also explicitly rely on the presence/absence of the QuasiQuotes and TemplateHaskell language options (iff QQ is on, [| ... |] means [quasiQuoter| ... |], forcing the explicit [e| ... |] for TH expression quotes). Better for one extension to steal syntax from another, perhaps, than stealing it from the base language. As Henrik points out (in his parallel reply) this only really matters if your quasi-quoted strings are quite short. I only recently came up with a use case in which a really terse quasi-quotation would be helpful; heretofore lengthy quotations were all that I had used. Nevertheless, the proposal as it stands would allow me to get away with a quasi-quotation that's only one character less terse than my 'implicit' suggestion would allow. Thanks, Rob ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Quasi quoting
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 enabled at the same time? One could decide in favour of QQs if they are enabled (though yes, this is likely horrible on the inside). Or we could switch to different quotation brackets altogether for quasiquotation, the obvious possibility being |...blah...|, and pads|...blah...|. [...] It's true; but I suspect `|' and `|' are actually widely used. Wouldn't `(|' and `|)' be safer? In either case, it's easy to see how me evolve an indentational quasi-quote syntax: `[|]' or `(|)'. If the default quasi-quoter is simple string literals, then there's no need for a HEREDOC in the language. -- Jason Dusek ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
