Re: Proposal: Lazy matching for local patterns

From: Michael Hanus <mh_at_informatik.uni-kiel.de>
Date: Mon, 29 Oct 2001 15:31:20 +0100 (MET)

German Vidal wrote:
> ... For instance, if accessor functions are always rigid,
> then "foo undefined" suspends with the definition
>
> foo eval flex
> foo n = let (x,y) in [x,y]
>
> while it does not suspend with the definition
>
> foo eval flex
> foo (x,y) = [x,y]
>
> Thus I would prefer that accessor functions have the same
> evaluation annotation as the function where the local declaration
> appear. Of course, I have no idea whether it is easy or difficult
> to incorporate into existing compilers. Is there any special
> trouble here?

I agree that the behavior in this case is somehow surprising
but the other solution could be equally surprising. If you use
several let's at various positions deep inside the right-hand side,
you have to consider the (far away) evaluation mode of the function
in order to determine the exact meaning of the let's. This could
be an argument in favor of a unique (local) treatment of accessor
functions (in addition to the difficulties with compilers
where it is easier to implement transformations with local conditions,
as already mentioned by Wolfgang).

It seems to me that this is again a situation where it is important
to point out that the "let" construct is just syntactic sugar
to support local definitions. It is a conservative extension
of the "let" in functional languages but becomes different
w.r.t. the functional logic extensions, e.g., the expression
"let x = f y in g x x" has the same meaning as "g (f y) (f y)"
in purely functional languages but has a different meaning
when f is a non-deterministic function.

So, I see no serious additional problems if we define the semantics
of the "let" with rigid accessor functions.

Best regards,

Michael
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Mo Okt 29 2001 - 15:33:23 CET

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