> No, I believe it wouldn't. The left-biased tree cannot distinguish
> where parentheses have been used from where HSE inserted its own left
> fixities. For instance, if we have the expressions
>
> xs ++ ys ++ zs
> (xs ++ ys) ++ zs
>
> Then HSE will return something like (I'm using strings for the
On Mon, Nov 24, 2008 at 12:39 AM, Niklas Broberg
<[EMAIL PROTECTED]> wrote:
>> 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
>> wh
> On Sun, Nov 23, 2008 at 8:23 AM, John A. De Goes <[EMAIL PROTECTED]> 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 pu
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 ->
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 mos
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 withou
> 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 si
This post follows on from a discussion about a month ago, called
"Haskell Syntax Inside Quasiquote".
To summarise, suppose I want to create a Haskell quasiquoter for lists, eg
[$list|1,x^2,y,3|] (representing the list [1,x^2,y,3])
Ideally, this would allow arbitrary Haskell expressions for
