Dear Sven,
thank you very much for your immediate reaction on the
updated Curry report.
You wrote:
> * IMHO it would be nicer if "success" was a *Constructor* of type
> Constraint. This would allow pattern matching on constraints. As it
> stands, the translation of conditional rules in section D.3 doesn't
> make much sense: In the rule (success => x) = x, success would be
> a simple variable. OK, it's only there for explanation, but with
> this small alteration, Success would not need any special treatment.
> BTW, is (=>) rigid or flexible? (It could be the case that
> success is meant to be a new keyword, but that would make things
> even worse.)
First of all, (=>) is rigid since it has type "Constraint -> a -> a"
and functions with polymorphic result type are rigid by default.
The question whether "success" should be a constructor is more
subtle. You are right, the rule "(success => x) = x" is not a valid
Curry rule but it is only used as a way to explain the operational
meaning of conditional rules without introducing a special inference
rule for it. However, if you think it is clearer to introduce
the handling of conditional rules in the inference system in
Figure 1 instead of this translation, I can change it.
The reason why "success" should not be considered as constructor
is that strict equality or pattern matching is usually defined
for all constructors. If "success" is a constructor, then one
might think to introduce negated constraints e.g. by writing
"not ((x=:=y) == success)" or similarly by pattern matching
(with the intention that this condition is satisfied
if x is different from y, even if both values are
currently unknown; however, if both x and y are unknown,
(x=:=y) is solved by binding x to y and the entire expression
reduces to False). Such constructions had been really used by
students when we taught Curry for the first time (at that time
there was no difference between constraints and Boolean functions)
and this experience led me to the conclusion that constraints
and the Boolean data type are two different things.
Constraints are restrictions on the domain of variables
(like "the value of x must be always equal to the value of y")
and thus should be considered as predicates on the constraint
store rather than Boolean expressions which correspond to a single
value (True or False). Thus, "Constraint" should not be viewed
as an algebraic data type like Bool or tuple but as a built-in
type without directly accessible constructors (like function types
or "IO a"). Consequently, "success" is just the neutral element
w.r.t. the conjunction "&" similarly to "id" for functions are
"done" for the IO monad.
> * Page 29, section 9: Change the reference to Boolean functions to
> functions returning a constraint.
Done.
> * It's not clear to me, if the pragmas flex/rigid and optmatch are
> meant to be orthogonal. If they are, optmatch should get a
> sibling pragma like funcmatch are whatsoever. If they are not,
> it should be made clear, which evaluation strategy accompanies
> optmatch.
I now clarified it explicitly on page 29. They are orthogonal but
I think a sibling pragma like funcmatch is not necessary since
this is the default. Note that flex/rigid both changes the default
and there is also no sibling pragma turning back to the default
since these pragmas are only provided once in the entire module.
> * Page 42, Prelude: getLine contains a nice little LaTeX-Bug...
Indeed, I changed it.
Since these three changes are very small (only the pages 29 and 42
are slightly corrected), I directly replaced the current version in
the web by the updated version without further comments.
> * As usual, I strongly recommend including a machine-usable grammar
> for Curry in the report, something like
>
> http://www.javasoft.com/docs/books/jls/html/19.doc.html
>
> for Java. Lessons learned from the past include the fact that
> ambiguous grammars or LR(k) grammars with k>1 are not only
> difficult for computers, but for humans, too... :-)
In principle, I agree. On the other hand, I think that a
machine-usable grammar is sometimes less readable for humans.
Therefore, I am in favor of a compromise: make a machine-readable
version of the grammar available in the web. The web page with
the Curry report contains a pointer to a page created by Sergio
which contains machine-readable (by JavaCC) grammar of an older
version of Curry (
http://www.cs.pdx.edu/~antoy/flp/syntax.html).
Hopefully it will be updated in the future.
> But the picture as a whole is encouraging: The language gets simpler,
> but more powerful and orthogonal!
I am also quite happy with the improvements we have made as an
outcome of the recent fruitful discussions. Thanks to all contributors!
Best regards,
Michael
Received on Mo Nov 23 1998 - 12:36:00 CET