Re: Strong encapsulation, weak encapsulation, and getSearchTree

From: Wolfgang Lux <wlux_at_uni-muenster.de>
Date: Wed, 16 Jun 2004 15:53:40 +0200

Hi Sergio!

> You were not cryptic. Perhaps, I was. What I meant to say is
> that the user should not have to say the order of evaluation, and
> perhaps should not be allowed to. I don't favor the use of seq.

I completely agree that the user should not need seq in order to get
a particular result. However, seq is a useful function in some cases.
For instance, it may be useful for improving performance and also can
help to avoid space leaks. IMHO, if Curry intended to be more than a
toy language, it should have seq. Also note that I used seq only in
order to describe clone's semantics (somewhat informally), so it is
very much clone's fault and not seq's.

> If the discussion is call-time vs need-time choice semantics, and
> the problem is to let the user select a semantics, then a clean
> solution is a language with a construct to let the user select a
> semantics.

With respect to let bound variables the situation is easy. One only
needs to be able to distinguish variable bindings and definitions of
nullary functions, for instance
   let x <- coin in x + x ~~> 0 | 2
   let f = coin in f + f ~~> 0 | 1 | 1 | 2
Incidentally, Concurrent Clean always had this distinction and
eventually Haskell is going to make this move at some time, too
(though probably with a different syntax), if only in order to
give an end to the ever recurring discussions about the monomorphism
restriction on the Haskell mailing list. However, such a proposal
does not extend in a straight forward way to function arguments.

Wolfgang


_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Fr Jun 18 2004 - 22:45:12 CEST

This archive was generated by hypermail 2.3.0 : Do Jun 20 2024 - 07:15:06 CEST