A few remarks to the new Curry report:
* 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.)
* Page 29, section 9: Change the reference to Boolean functions to
functions returning a constraint.
* 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.
* Page 42, Prelude: getLine contains a nice little LaTeX-Bug...
* 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... :-)
But the picture as a whole is encouraging: The language gets simpler,
but more powerful and orthogonal!
Cheers,
Sven
--
Sven Panne Tel.: +49/89/2178-2235
LMU, Institut fuer Informatik FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen Oettingenstr. 67
mailto:sven.panne_at_informatik.uni-muenchen.de D-80538 Muenchen
http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne
Received on Fr Nov 20 1998 - 15:31:00 CET