- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]

From: Michael Hanus <mh_at_informatik.uni-kiel.de>

Date: Fri, 17 Mar 2006 14:04:59 +0100

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 Fri Mar 17 2006 - 17:25:43 CET

Date: Fri, 17 Mar 2006 14:04:59 +0100

Wolfgang Lux wrote:

Thanks for your careful reading!

Indeed, I forgot this and now it is corrected.

Evaluation annotations no longer exists and a proposal

for "commit" is added.

Thanks, corrected.

No, so now I omitted this typing rule.

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 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.

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.

Ok, added.

Done. However, I must admit that I have no expectations

about an order between False and True.

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.

Thanks for the hint, I have added them.

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 Fri Mar 17 2006 - 17:25:43 CET

*
This archive was generated by hypermail 2.3.0
: Thu Sep 19 2019 - 07:15:06 CEST
*