Precedence of infix operators

[dag.od...@gmail.com]

From IRC:

<luite_> I'm not sure what kind of requirements HSX has,
         but template haskell allows you to output an AST with unresolved associativity

Is it possible we could do that for HSX? Somehow just pass it through as it is in the source?

In any case what currently happens is you get an error message with no pointers to the location of the problem. If just that could be fixed it would help a lot!

--
Dag

[Niklas Broberg]

Hi Dag,

I'm not sure what's asked for exactly, but I believe the answer is "yes, haskell-src-exts can do that". When generating an AST, nothing forces you to resolve any fixity. When parsing a source file, you can turn off fixity resolution in the ParseMode, e.g. 'parseFileWithMode (defaultParseMode { fixities = Nothing }) myFile'.

Also, fixity resolution is being improved to include better error messages. But that's a different story.

Cheers,

/Niklas

--
You received this message because you are subscribed to the Google Groups "Haskell Server Pages" group.
To post to this group, send email to haskell-se...@googlegroups.com.
To unsubscribe from this group, send email to haskell-server-p...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/haskell-server-pages?hl=en.

[dag.od...@gmail.com]

On Wed, Apr 18, 2012 at 8:42 AM, Niklas Broberg <niklas....@gmail.com> wrote:

Hi Dag,

I'm not sure what's asked for exactly, but I believe the answer is "yes, haskell-src-exts can do that". When generating an AST, nothing forces you to resolve any fixity. When parsing a source file, you can turn off fixity resolution in the ParseMode, e.g. 'parseFileWithMode (defaultParseMode { fixities = Nothing }) myFile'.

OK, so if I run trhsx on this:

https://github.com/dag/happaste/blob/master/src/Happaste/Routes.hs

$ trhsx src/Happaste/Routes.hs
Ambiguous infix expression

The issue is the sitemap definition on line 39, but GHC is happily accepting it since it knows the precedence of the (<>) and (</>) operators from boomerang. I can work around it with extra parenthesis, of course.

I was first thinking that this issue isn't easily solvable since src-exts would have to know the precedence of imported operators, but luite's comment on IRC had me wonder if that was really the case.

[Niklas Broberg]

On Wed, Apr 18, 2012 at 9:40 AM, dag.od...@gmail.com <dag.od...@gmail.com> wrote:

OK, so if I run trhsx on this: 

https://github.com/dag/happaste/blob/master/src/Happaste/Routes.hs

$ trhsx src/Happaste/Routes.hs
Ambiguous infix expression

The issue is the sitemap definition on line 39, but GHC is happily accepting it since it knows the precedence of the (<>) and (</>) operators from boomerang. I can work around it with extra parenthesis, of course.

I was first thinking that this issue isn't easily solvable since src-exts would have to know the precedence of imported operators, but luite's comment on IRC had me wonder if that was really the case.

Ah, I see. The problem is of course that trhsx resolves using baseFixities, with no possibility to override. My fault entirely.

So then the question is, will anything in HSX.Transform break by not knowing anything about the semantics of operators? A quick scan of the code says no - infix applications are simply treated as structural boilerplate. In other words, it should be safe to turn off fixity resolution completely. I'll do that for the next release (which will come sooner than you'd think!).

Cheers,

/Niklas

[dag.od...@gmail.com]

On Wed, Apr 18, 2012 at 11:20 AM, Niklas Broberg <niklas....@gmail.com> wrote:

I'll do that for the next release (which will come sooner than you'd think!).

Cool, thanks a bunch!