Though many see it as "losing" information, I agree wholeheartedly
with your proposal to change the AST.
It's better to have an AST that conveys less information, but
truthfully, than to have an AST that purports to convey more
information, when in fact that information is false.
In most languages, some things just can't be known at parse time. They
need to be resolved later.
In this case, the most important thing is following the principle of
least surprise: A Haskell expression inside a quasiquote should work
the same as a Haskell expression outside a quasiquote.
Violating the "principle of least surprise" is one of the most
grievous mistakes language (and interface) designers make.
Regards,
John A. De Goes
N-BRAIN, Inc.
http://www.n-brain.net
[n minds are better than n-1]
On Nov 22, 2008, at 9:02 AM, Reiner Pope wrote:
It seems to me that fixity information behaves more like semantics
than like syntax. For instance, fixities may be imported, and obey
namespacing rules. Knowing and correctly handling these rules seems
beyond the scope of a mere parser: I would hope that a single Haskell
file could be parsed without reference to any files, and fixity
declarations seem to be just about the only thing which prevent this
-- hence my suggestion to change the AST in order to regain this
property.
The use I envision of it is as I described: writing a quasiquoter
using HSE to parse the user's Haskell expressions. The problem is
that, for such a case, HSE (or any other parser) is forced to parse
infix expressions for which it cannot possibly know the correct
fixities. Any result with more information than the list form I gave
would be a lie.
I realise that I don't know how fixities are implemented in Haskell
compilers, so perhaps I'm misunderstanding how they are treated.
Cheers,
Reiner
On Sat, Nov 22, 2008 at 11:54 PM, Niklas Broberg
<[EMAIL PROTECTED]> wrote:
Of course, this would require a change to Template Haskell, so a
second-best solution would be to forbid unparenthesised
expressions in
my quasiquoter. Then, parsing can proceed correctly without knowing
the fixities. This would be easiest to do if haskell-src-exts
changed
its AST in a similar way to described above for Template Haskell.
I'm not sure I follow you here. In what way would it be simpler if
HSE
changes its AST to a less-information constructor? I won't do that,
for the same reason you point out with TH and disadvantages when
using
it as a library, though I'm still curious what uses you envision and
how it would be made easier. I'm still in the process of designing
the
fixity support for HSE, and all input is valuable. :-)
Cheers,
/Niklas
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
