Quasi quoting

[Dave Bayer]

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 fine, sorry about the long post which you may freely ignore. What I read when I see "stealing syntax" is that a proposal makes some prior code impossible to write. Please clarify.

I have no trouble distinguishing visually between the following forms

	[hex| 1.fffffp+1023 |]

	[ hex | hex <- [ 0..8 ] ]

for two different reasons:

[1] I'd never leave out the spaces for the list comprehension, while I'd always leave out the spaces for quasiquoting.

[2] It's completely obvious to a human reader that the first form can't be a list comprehension, because of the trailing |] which would be a parse error.

Let's recall that indentation-based parsing like we use in Haskell, Python was once radical, and still jars some people. Spaces are already significant for everyone, this just leans on them a bit more. A Lisp programmer would have no issues distinguishing these forms, because [hex| is a single token for the Lisp programmer. A freshman parser for quasiquoting would get this right by accident, failing to catch the quasiquoting that used spaces, falling correctly through to the list comprehension.

More generally, humans always resolve ambiguity by parsing several ways in parallel, and accepting the highest priority parse that succeeds. I always expect computer languages to work this way, and my heart is always broken. Why can't Haskell evolve in this direction, as proposals like this increase its code density? Reading "Coders at Work", all of my coding zombie masters abandoned Lisp (as I did) because code density is a Good Thing.

It's a mild nuisance to wait on the closing |] to decide, but only a mild nuisance. This reminds me of heredocs, where a traditional (e.g. Perl) heredoc

 help prog = <<“EOF”
Usage:
 “prog” input output
 “prog” -h original input output
   EOF

looks like it's stealing syntax, but there is utterly no issue at all, if one waits till the end to resolve the ambiguity, giving priority to a correct heredoc. (I need to wait till the end in any case to steal the indent.) Somehow this was never accepted as a reasonable idea in the heredoc thread either, yet I took this from working code that my custom literate preprocessor handles without incident.

So what am I missing? Require no spaces to open quasiquoting, and/or require |] to close quasiquoting, falling through to whatever else Haskell will accept if these conditions aren't met? Then it remains possible to code any list comprehension.

On Jan 31, 2010, at 10:50 PM, Simon Peyton-Jones wrote:

>      So the proposed change will make things *more* uniform, by grabbing every
>      "[blah|" as lexeme. 

On Feb 1, 2010, at 1:43 AM, Malcolm Wallace wrote:

> 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.

On Feb 22, 2010, at 5:15 AM, Simon Peyton-Jones wrote:

> Or, alternatively, use quasiquoting
> 	
> 	[hex| 1.fffffp+1023 |]