Curry language changes

From: Michael Hanus <hanus_at_informatik.rwth-aachen.de>
Date: Thu, 25 Nov 1999 11:08:46 +0100 (MET)

Dear Colleagues,

during the last FLOPS conference in Tsukuba, there was a meeting
with Sergio Antoy, Herbert Kuchen, Wolfgang Lux and me where
we discussed a few changes w.r.t. the current definition
of Curry. I summarize the proposed changes below.

1. "pragma optmatch"
====================
Currently, the default definition of pattern matching
is left-to-right in order to be compatible with Haskell.
However, since it is known that this pattern matching is
not optimal and can be easily improved, there is the
pragma "optmatch" to enable the better pattern matching.
To see the difference, look at the following example:

  g 0 [] = 0
  g _ (x:_) = x

  h x = h x

Since Haskell does pattern matching from left to right,
it will not terminate for the expression "(g (h 0) [1])".
With the pragma optmatch, Curry will compute the value "1"
for the same expression. One might think that this example
is artificial but there is another drawback of left-to-right
pattern matching shown by this example: although the program
is inductively sequential (which means that all evaluations of
ground terms can be deterministic), left-to-right pattern matching
introduces a disjunction (or-node in the definitional trees)
so that computations becomes non-deterministic. This property
has really negative consequences since, if computations becomes
non-deterministic, one needs to encapsulated them between I/O
operations where there is really no need to do it. Although
one can always add the pragma optmatch to avoid it, the
default left-to-right pattern matching is really a pitfall:
I and also some other colleagues spent a lot of time for
debugging (mainly in distributed applications written in Curry,
which is non-trivial!) where at the end the only reason was
the non-optimal default pattern matching.

Therefore, here is the proposal:
Omit the pragma optmatch and make it as default!

Of course, this is no longer compatible with Haskell, but the
only incompatibilities are:
- Curry programs terminate and compute a result where Haskell
  does not terminate: we think this is a nice behavior and which does
  not cause problems.
- Curry programs perform evaluations steps in a different order
  than Haskell: since the final results are identical (if Haskell
  terminates), this seems also not to be a problem.


2. Name of datatype "Constraint"
================================
Mario Rodriguez remarked that the name of the datatype "Constraint"
is misleading, since its elements are not constraints but it denotes
a domain containing only one truth value as the single non-trivial
element (in contrast to "Bool" which contains two truth values),
i.e., negation of constraints is not directly defined but must
be supported by a constraint solver (e.g., disequality constraints
in Toy). Thus, what is traditionally considered as a constraint
is an element of the function domain (t1->...->tn->Constraint),
e.g., (=:=)::a->a->Constraint is the standard equational constraint.
To avoid thess misunderstandings and make the notions clearer,
we suggest to change the name "Constraint" into a name related
to a domain with only a positive truth value. Proposals are
- Success (since "success" is currently the corresponding function)
- Valid (for validity)
- Truth (for indicating the this domains can only express truth)

If we adapt e.g. "Success", then one can say that a "constraint"
is a function with result type "Success", which avoids some of the
misunderstandings with the current names.


3. Literate programming
=======================
After developing more applications and libraries for Curry,
some of us had the feeling that the literate programming style
should be added to Curry for better documentation. The literate
programming style encourages the use of comments for the
documentation of programs since in this style comments
are the default case. Non-comment lines containing program code
must start with ">" followed by a blank. To distinguish
literate programs from standard programs, they must be stored
in files with the extension ".lcurry" (instead of ".curry").
The implementation is not a big deal, since one can easily
write a shell script (thanks Sergio!) to translate .lcurry programs
into .curry programs.


That's all for the moment. Comments are welcome!

Best regards,

Michael
Received on Do Nov 25 1999 - 11:10:57 CET