Dear Michael, Herbert,
I've had a quick look at the Curry document, and I have a suggestion
to make. It is this:
use Haskell's syntax and semantics wherever possible
Please do not dismiss this too quickly as a self-interested
suggestion, though I know it may appear to be one. Consider:
* Syntax is (a) simultaneously trivial and very important, (b) very
hard to get "right", and (c) infernally difficult to agree on by
email. In short, it is not easy to do a good job, and it costs a
*lot* of effort to do so.
There's a lot to be said, therefore, for adopting the syntax of some
existing language, that has already had a lot of effort invested in
it. You want to choose a language that is close in spirit to what you
are doing, and I think that Haskell is probably the closest. For
example, Haskell has pattern matching (just as you want), *including
guards* with the right semantics (choose the next equation if this
guard doesn't match).
* You want to seduce people into using your language. The more it
looks and behaves like something they know, the more likely they are
to use it. The more it differs in tiresome ways the less likely they
are to use it.
* For the purposes of this message, by "syntax" I include "module
system". Haskell has quite a nice module system now, which is based
entirely on the simple idea of controlling name spaces. There is no
prescribed format for interface files, which is an advantage for you.
I think it will do just what you want.
Again, it is the result of megabytes of email, and it's in pretty good
shape.
* Implementations will come along faster if there are parsers
available that already do 90% of the job. Doing the parser is a
surprisingly large job. (Error recovery, line numbers, layout rules,
user-defined precedences...)
* Curry is an upward extension of both functional and logic languages.
However, logic languages have traditionally been untyped and
syntactially emaciated, so a functional language makes a much better
base (as you say). So it makes sense to make Curry into Haskell++.
It would be a delightful thing if every Haskell program was a Curry
program! The only reason for not doing so is that you want to avoid
the class system. Fair enough; but it's a good principle to follow
wherever you can.
* Our research community is always in danger of becomming fragmented into a
million separate groups. Haskell, for all its faults, has had a very
unifying effect. That's not something to discard lightly.
Short summary
~~~~~~~~~~~~~
Concentrate on your main innovation, and refrain from innovating
anywhere you don't have to. If you invent everything from scratch
you'll slow down your design a great deal, and reduce uptake from your
users.
The current Curry design differs form Haskell in many places
where it could be identical. I think that represents a big missed
opportunity.
Simon
Received on Mi Dez 18 1996 - 09:32:21 CET
This archive was generated by hypermail 2.3.0
: Do Feb 01 2024 - 07:15:04 CET