[Haskell-cafe] Function Precedence

Hans Aberg haberg at math.su.se
Wed Apr 2 09:16:51 EDT 2008


On 2 Apr 2008, at 14:27, jerzy.karczmarczuk at info.unicaen.fr wrote:
>> That is possible, of course - I did that, too. But it means that  
>> the  syntax and semantics do not work together; an invitation to  
>> pitfalls.  So this ought to be avoided, except if there are no  
>> other workarounds.
>
> I am more tolerant.

The pragmatics is to decide whether to program Haskell, or making a  
new language. I am interested in the latter, but realistically nobody  
will singly be able prdocue the programingg capacity that the now  
mature Haskell has.

> The question - for me - is not an interplay between
> syntax and semantics, ...

That interplay, between notation and notions, is very important in  
math, as if the do not flow together, one will not be able to  
describe very complex logical structures.

> ...syntax here is irrelevant, the fact that (+) is a
> popular infix operator plays no role. The calamity comes from the  
> fact that
> it is not possible to write serious and "natural" instances of Eq and
> Show for functions, ...

A correct Eq would require a theorem prover. Show could be  
implemented by writing out the function closures, but I think the  
reason it is not there is that it would create overhead in compiled  
code.

> ...and that for God knows which reasons, the Num instance
> demands them ! This requirement is not rational, although intuitive.

Probably pragmatics. More general implementations were not considered  
at the time.

> But
> I violated it several times, when I needed arithmetic for lazy  
> infinite
> objects... So, I can't say that this should be avoided. I don't see
> "obvious" pitfalls therein.

The pitfall is when somebody which does not know the code well tries  
to use it. Define a library with
   false = True
   true = False
Perfectly logical, but it will be thwarted by peoples expectations.

>> It would be better to write a new Prelude. :-)
>
> Oh, yes, our common dream...

Such changes will require a new standard. Haskell seems rather fixed,  
so it will perhaps then happen in a new language. :-)

   Hans




More information about the Haskell-Cafe mailing list