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 <[EMAIL PROTECTED]> wrote:
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
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
