Wolfgang Lux wrote:
> I have a few comments.
Thanks for your careful reading!
> With regard to evaluation annotations, I think it was consensus
> on this list to get rid of eval choice annotations, too, and
> introduce a new primitive function commit for committed choice.
> http://www.informatik.uni-kiel.de/~curry/listarchive/0297.html
Indeed, I forgot this and now it is corrected.
Evaluation annotations no longer exists and a proposal
for "commit" is added.
> Furthermore, I found two places in the report where let-free
> expressions are still restricted to constraints, namely:
Thanks, corrected.
> BTW, is there any reason for including the boolean conditional in
> the typing rules? After all, according to the report an expression
No, so now I omitted this typing rule.
> In the prelude, I have been puzzled a bit by the somewhat complicated
> definition of the operator ($##), which applies a function to an
> argument that is evaluated to a ground normal form:
> f $## x | x=:=y = y==y `seq` f y where y free
I must admit and this definition looks complicated,
but the intention was to define anything in terms of
existing operations in order to show that no new primitive
is necessary.
> I would propose to add a new primitive function ground with type
> signature
> ground :: a -> a
> to the prelude, which evaluates its argument to a non-variable head
> normal form (like ensureNotFree) and also applies ground recursively
> to all arguments of the result (if any). With that function, the
> definition of ($##) becomes
> f $## x = f $!! ground x
> which IMHO expresses the intent of the operator in a much cleaner way
> than the current definition. In addition, I also like the symmetry
> between this definition and that of $#.
I agree that the primitive ground makes the definition more elegant.
On the other hand, adding a new primitive (which is also nontrivial
as strict equality since it performs a recursion on arbitrary terms)
also complicates the language and efforts for the implementors.
>From our experience, every new primitive, in particular
recursion operators like =:=, == etc., requires considerably
effort not only for the language implementation but also
for various tools like debuggers, profiles, analyzers etc.
Thus, I am in favor to avoid such primitives whenever possible.
Note that ($##) is mainly intended to prepare
arguments of external functions where such details are not
so important.
> Furthermore, it is nice having a data type Ordering in the prelude,
> but it would be more useful if there were also a compare function using
> this type and it would be even more useful if this function had a
> polymorphic type signature, i.e.
> compare :: a -> a -> Ordering
Ok, added.
> If a polymorphic compare is added in this way, the definition of
> Bool in the standard prelude should be changed into
> data Bool = False | True
> so that False `compare` True = LT as one would expect.
Done. However, I must admit that I have no expectations
about an order between False and True.
> The operational semantics in appendix D still distinguishes flex and
> rigid branch nodes in definitional trees.
This is intended since the operational semantics is based on these
trees so that both function patterns as well as case expressions
should be translated into defintional trees with flex and rigid
branch nodes, respectively. Note the remark in Appendix D.1:
"User-defined functions are always translated into definitional trees
with flex tags, but case expressions are translated
into definitional trees with rigid tags."
However, the translation of case expressions is not yet
previsely defined in the report.
> Instead, the operational semantics should include the following rules
> for ensureNotFree:
Thanks for the hint, I have added them.
> On p.80 in Sect. D.6 there are also still references to the evaluation
> annotation modes, in the left hand side of the function gt, and in the
> example tree at the bottom of the page.
I have removed the parameter "m" from gt (and put always "flex"
in the branch node). What is still missing is a translation of
case expressions via a similar function.
A new version with the updates discussed so far is in the
web pages.
Best regards,
Michael
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Fr Mär 17 2006 - 17:25:43 CET