Hello,
In the haskell-src-exts quasi quoter there is some code to convert all
names in `dataToQa` to global names. The reasoning is according to the
source:
-- | The generic functions in 'Language.Haskell.TH.Quote' don't use global
-- names for syntax constructors. This has the unfortunate
I believe I fixed this problem in Language.Haskell.TH.Quote for the
7.4.1 release. The fix is in revision c4c250 of the template-haskell
library.
Geoff
On 02/18/2013 03:11 PM, L Corbijn wrote:
Hello,
In the haskell-src-exts quasi quoter there is some code to convert all
names in `dataToQa` to
Perhaps I missed this or I'm missing something, but seeing a mention of
quasiquoting on another thread, I reread this entire thread just now before
posting.
If by stealing syntax we mean that the odd programmer who writes
illegiblelinenoisewithoutspaceshastoaddtheoddspacehereandthere, then
marlowsd:
On 03/02/2010 15:39, Simon Peyton-Jones wrote:
| 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
| Subject: Re: Quasi quoting
|
| Dominic Orchard and I have come up with a rather radical proposal for
| a redesign of the syntax. There are two principal options:
|
| OPTION 1 (preferred)
| ===
|
| Advantages:
| 1) QuasiQuotes are revealed as they really are - as splices. In my
-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
| users-boun...@haskell.org] On Behalf Of Sebastian Fischer
| Sent: 02 February 2010 11:04
| To: Simon Peyton-Jones
| Cc: glasgow-haskell-users@haskell.org; Kathleen Fisher;
| mainl...@eecs.harvard.edu
| Subject: Re: Quasi quoting
|
| Dear
On 03/02/2010 15:39, Simon Peyton-Jones wrote:
| 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.
although both create Exp values.
And then write:
$(myLang [|...|])
This is more verbose than the proposed [myLang| ... |]. There seem to
be different goals in the different proposals in this thread: 1.
Simplify the syntax for quasi quoting (remove $, use different
brackets), 2. make it more
On February 2, 2010 19:48:27 Max Bolingbroke wrote:
It's a shame that TH is too widely used to be amenable to refactoring
into this sort of form.
I thought the standard thing to do in this case was to add either a pragma
that gives you the new behaviour or trigger it with an alternative syntax
| 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
| But it'd remove | and | as a
| valid operators, at least for quasiquote customers. I don't know
| how bad that would be.
|
| Good brackets are scarce. I'd prefer to stick with one of the many
| fine variations on [|...|] currently being discussed.
I agree with this. My gut feel
, and is more of an
unintentional feature than something I was designing for :-)
This is more verbose than the proposed [myLang| ... |]. There seem to be
different goals in the different proposals in this thread: 1. Simplify the
syntax for quasi quoting (remove $, use different brackets), 2. make
On Feb 3, 2010, at 6:13 PM, Max Bolingbroke wrote:
With a class-based approach only one parser that creates values of
the same
type could be used in a program.
This is not the case, because you still have an instance Quoted
String. Then you can write:
$(myLang [|..|])
Where myLang ::
On 01/02/2010 14:25, Max Bolingbroke wrote:
Dominic Orchard and I have come up with a rather radical proposal for
a redesign of the syntax. There are two principal options:
OPTION 1 (preferred)
===
Advantages:
1) QuasiQuotes are revealed as they really are - as splices. In my
Dear Simon,
I want to generate data type declarations using quasi quotes and hence
support the proposal to allow quasi quotation at declaration level.
With respect to syntax, I'd prefer [|blah| ... |] over the current
[$blah| ... |] and would also be fine with [blah| ... |].
What is the
On Feb 1, 2010, at 11:46 PM, Jason Dusek wrote:
Wouldn't `(|' and `|)' be safer?
I like this suggestion. It avoids conflicts with Template Haskell and
list comprehensions. Conor McBride also picked these brackets as idiom
brackets in his preprocessor she.
[$blah| ... |] could be
(Sorry if you see this twice, Simon - I didn't reply to the list)
2010/2/2 Simon Marlow marlo...@gmail.com:
Can you say precisely what it means to be in an Exp context?
In a Type context == a HsSpliceTy constructor in the existing GHC AST
In an Exp context == a HsSpliceE constructor in the
On 02/02/2010 15:40, Max Bolingbroke wrote:
(Sorry if you see this twice, Simon - I didn't reply to the list)
2010/2/2 Simon Marlowmarlo...@gmail.com:
Can you say precisely what it means to be in an Exp context?
In a Type context == a HsSpliceTy constructor in the existing GHC AST
In an Exp
Max Bolingbroke wrote:
...
In this proposal, you can then export t and d functions from
Language.Haskell.TH with the type:
t :: String - Type
d :: String - [Decl]
Which parse the provided string as Haskell. This allows existing any
uses of Template Haskell to remain *unchanged* (as long as
2010/2/2 Isaac Dupree m...@isaac.cedarswampstudios.org:
I'm concerned in both your proposals, that single-letter names like t and
d are common function parameters, thus possibly producing
- shadowing warnings for all such functions in modules that happen to use TH
- errors, I think, for some
Hello Max,
Tuesday, February 2, 2010, 7:25:36 PM, you wrote:
You can of course choose more expressive names than e and t if
you're going to break backcompat anyway,
i propose x and xs :D
--
Best regards,
Bulatmailto:bulat.zigans...@gmail.com
Max Bolingbroke wrote:
2010/2/2 Isaac Dupree m...@isaac.cedarswampstudios.org:
I'm concerned in both your proposals, that single-letter names like t and
d are common function parameters, thus possibly producing
- shadowing warnings for all such functions in modules that happen to use TH
-
2010/2/2 Twan van Laarhoven twa...@gmail.com:
class Quoted a where
parseQuote :: String - a
-- for performance reasons:
parseQuote' :: Ghc.PackedString - a
Great idea!
Thinking about it, you can use type classes to dispose of the
QuasiQuote record entirely. Instead,
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|
[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
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
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
33 matches
Mail list logo
