Philip Wadler wrote:
> Good point, and well worth stressing. Nonetheless, it still seems
> quite reasonable to say that Curry should contain all Haskell
> that eschew type classes and non-uniform pattern matching.
I think this is a good remark and I can agree to it.
I have no problems to change to current proposal and make
it very close to Haskell. The changes which I made were mainly
influenced by colleagues who told me about problems with some "overloaded"
notations of Haskell when they teach the language. But I can
imagine that it may be better not to try to change currently
used notations. So, I will try to consider your arguments
in the next version of the proposal. Unfortunately, only
the "functional-programming-oriented" people have answered
so far on this mailing list, but I hope that the LP people
can also agree. In particular, I am interested in the opinion
of the Escher designers, since they use a syntax which is
completely different from Haskell and from Prolog.
Concerning uppercase/lowercase: of course, we can or should
use Haskell's *convention*, but I do not like to enforce it,
i.e., programs using other conventions are also valid programs.
This has the nice feature that Haskell programs are already
valid Curry programs (except for type classes and non-uniform
functions), and it is easier to convince logic programming
people since there is a straightforward and "LP-readable"
translation of logic programs into Curry. Maybe, in the far future,
everybody uses the same convention (and also colored identifiers,
as I mentioned yesterday...).
So, we have to find another notation for "constraint" equality,
which is very similar to the strict equality == of Haskell
but performs unification in the presence of logical variables,
which is necessary to cover (C)LP applications.
If we take non-uniform programs into account, they are sometimes not
valid Curry programs. However, I suppose that it is fairly easy to
translate them into Curry programs with the same meaning by
adding negative conditions to the subsequent equations.
For instance,
f 0 = 0
f x = 1
could be translated into
f 0 = 0
f x | not x==0 = 1
For ground expressions, the meaning of the latter (Curry) program
is identical to the first one. Although the latter version
seems to be not so efficient as the first one, maybe a good compiler
can produce the same code if he knows that f is only called
with ground arguments.
Best regards,
Michael
Received on Do Dez 19 1996 - 16:28:46 CET
This archive was generated by hypermail 2.3.0
: Do Feb 01 2024 - 07:15:04 CET