We all seem agreed that
Haskell is a proper subset of Escher is a proper subset of Curry.
Immediately this raises the questions (John asked the second of these):
What useful things can Escher do that Haskell cannot?
What useful things can Curry do that Escher cannot?
Of course, there's no doubt that we can write programs in Curry that
we cannot write in Escher, and programs in Escher that we cannot write
in Haskell. Michael gave a simple example.
Curry:
f a = b
f c = d
main = { x | f x = b }
Escher:
fp x y = x == a && y == b || x == c && y == d
main = { x | f x b }
Haskell:
fl = [(a,b), (c,d)]
main = [ x | (x,y) <- fl, y == b ]
(Sorry, I expect that the `main' lines are not quite legal for
Curry or Escher, perhaps someone could correct these for me.)
But this example is too simple to be convincing. All three programs
work tolerably well for this trivial problem.
The real question is: what is your killer app? What application
areas does this language address, that are not so well addressed
by existing languages? Here are examples of the sort of answers
I would give for some other languages.
Haskell (or Standard ML):
Compilers (e.g., Haskell and SML compilers)
Theorem provers (e.g., Veritas, Isabelle, HOL)
Natural language understanding (e.g., Lolita)
Erlang:
Phone switches (e.g., Ericsson Mobility server)
Prolog:
Databases
Natural language understanding
Search problems
Java:
Networking applications and portability
The particular programs I quote are on the order of tens of thousands
of lines long (with the exception of Erlang's mobility server, which
is about a quarter of a million lines). Also note that I haven't
listed any killer apps that distinguish lazy and strict functional
languages.
Perhaps it's unreasonable to ask John or Michael to point at
ten-thousand line long programs in Escher or Curry. But I think it's
eminently reasonable to ask from what fields you expect your killer
apps to spring.
It's also important to delimit where you think your language is
inappropriate. Haskell would not be my first choice for scientific
programming or systems programming (some have tried to apply Standard
ML to systems programming, but the success has been limited). Erlang
is designed for soft real-time, distributed systems; it's no good for
hard real-time.
It's also important to have good models of how your system behaves at
run-time. I'm unconvinced by John's description of Escher, as I want
to be able to predict which programs reach an answer and which do not,
and his description doesn't let me do so. This, by the way, is one of
the great drawbacks of functional languages: while it is fairly
straightforward to predict how much time they require, it is quite
difficult to predict how much space they will use. (One of the recent
advances has been tools that at least allow us to measure space use.)
Both Escher and Curry have technically fascinating aspects, but if
someone asked me to say where they might find practical application I
could give no answer. I would quite like to be able to do so, so I
look forward to your replies!
Cheers, -- P
-----------------------------------------------------------------------
Philip Wadler wadler_at_research.bell-labs.com
Bell Laboratories
http://cm.bell-labs.com/cm/cs/who/wadler/
Lucent Technologies office: +1 908 582 4004
700 Mountain Ave, Room 2T-304 fax: +1 908 582 5857
Murray Hill, NJ 07974-0636 USA home: +1 908 626 9252
-----------------------------------------------------------------------
Received on Do Jul 03 1997 - 19:14:00 CEST