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 |]
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
