[Haskell-cafe] Re: Re: non-total operator precedence order (was:Fractional/negative fixity?)
Henning Thielemann wrote: On Fri, 10 Nov 2006, Benjamin Franksen wrote: Although one could view this as a bug in the offending module it makes me somewhat uneasy that one additional import can have such a drastic effect on the code in a module /even if you don't use anything from that module/. It's the same as with instance declarations, isn't it? I don't want to defend the problems arising with todays anonymous instance declarations, Right. However, with instances I can imagine solutions that avoid naming them, that is, I could imagine to write something like select instance C T1 T2 ... Tn from module M or import M hiding (instance C T1 T2 ... Tn, ) Such a feature could prove extremely useful in practice. Disclaimer: I am almost sure that there is something I have overlooked that makes such a simple solution impossible, otherwise it would have been proposed and implemented long ago... but I think a simple error report is better than trying to solve the problem automatically and thus hide it from the programmer. I agree 100% that error is better than silently change (fix) semantics. However the fact that there is currently no way to manually resolve instance clashes coming from imported (library) modules is really problematic, IMHO. I think the only reason this hasn't yet produced major upheaval is that Haskell community is still quite small so library writers can still have most of the field in their eyeview, so to speak. If Haskell libraries were written and used in multitudes such as seen e.g. on CPAN, then the probability of conflicting instances would be a lot greater, in turn causing many libraries to be incompatible with each other. IMHO, this must be fixed before Haskell reaches even a fraction of that level of popularity. Non-total precedence order will give us more potential incompatibilities that the programmer has no way of resolving satisfactorily, so I'd rather stick with the current system, however limited. (And yes, I /have/ changed my mind on this. I'd /love/ to be convinced that this is not really going to be a problem but I am not and I hate it.) Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Re: non-total operator precedence order (was:Fractional/negative fixity?)
Jan-Willem Maessen wrote: On Nov 9, 2006, at 7:16 PM, Benjamin Franksen wrote: Carl Witty wrote: If you have operators op1 and op2, where the compiler sees conflicting requirements for the precedence of op1 and op2, then they are treated as non-associative relative to each other: the expression a op1 b op2 c is illegal, and the programmer must instead write (a op1 b) op2 c or a op1 (b op2 c) It's a possibility. However, I fear that such conflicting precedences might not come in nice little isolated pairs. For instance, each operator that is in the same precedence class as op1 (i.e. has been declared as having equal precedence) will now be 'incompatible' with any that is in the same class as op2, right? Well, look at it from the perspective of the reader. Does the reader of your code know beyond a shadow of a doubt what the intended precedence will be in these cases? If not, there should be parentheses there---quite apart from what the parser may or may not permit you to do. If the parser can't figure it out, you can bet your readers will have trouble as well. Imagine op1=(+), op2=(*). Would you think that it is acceptable if any wild module can come along and destroy the relative precedence order everyone espects to hold between those two? For this to happen it would be enough if M1 says prec (+) = prec (+) prec (*) = prec (*) while M2 says prec () = prec (*) and M3 prec () = prec (+) All modules M1, M2, and M3, when viewed independently, and even when viewed in pairwise combination, don't do anything bad. It is only the combination of all three that cause the expression 3 + 4 * 3 to become a syntax error! Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
