I would imagine (reading into Jon Fairbairn's note) that the
difficulty is in combining it with the traditional handling of
precedences in parsing systems, as Bulat was describing. AFAIK, which
is not much on this topic, the notion of precedence in traditional LR
spewers is strictly tied to numeric precedences that are known pretty
much a priori.
Since mapping all the way to numbers seems like overkill to resolve
such infix ambiguities, I'd expect such an adjustment to parser
generators wouldn't be horrific--it may even be more natural on the
implementation side.
Nick
On 10/16/06, Arie Peterson
Good evening,
Bulat Ziganshin wrote:
but when you want to have user-defined operators, that will mean that you need either to define precedences to all other operators (including those from other libs), or sometimes user programs will not compile because they used combination of operators with undefined precedence
good for making good headache :)
Why is that?
A library would indeed only declare the relative precedence of its operators with respect to operators that 1) it knows of; and 2) are related (or general) enough so that there is a reasonable choice of precedence. I think it is even good to force the user to declare any other, more uncommon, precedences; better than the current situation, where the relative precedence of operators from unrelated libraries is fixed pretty much arbitrarily, as an artefact of the imposed total order.
Regards,
Arie
--
Mr. Pelican Shit may be Willy.
^ /e\ ---
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe