[Haskell-cafe] Fixity parsing, Template Haskell

[Reiner Pope]

It turns out that there is at least a (partial) solution to my
quasiquote problem. Template Haskell's "reify" function can be used to
find an operator's fixity, although it seems not for all cases.
However, for the purposes of this discussion, suppose I can write a
function

userFixity :: String -> Q Fixity

which takes a operator used in user code and returns its fixity, in
the Q monad (Template Haskell's monad).

I want this information to be used somehow when creating the Template
Haskell AST, so that the operators used have the correct fixities. If
I use HSE for parsing Haskell expressions, then I want it to tell me
where it unsure of the fixities, so that I can insert the correct ones
there. For this use case, I would want HSE to use an AST like I
suggested, because it allows the parser to say, "I'm not sure what the
correct fixity is".

Cheers,
Reiner


On Sun, Nov 23, 2008 at 8:23 AM, John A. De Goes <john at n-brain.net> wrote:
>
> 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
>> <niklas.broberg at gmail.com> 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>