Re: New PAKCS release (Version 1.8.0)

From: Emilio Jesús Gallego Arias <>
Date: Fri, 30 Mar 2007 12:31:48 +0200

Wolfgang Lux <> writes:

> Emilio Jesús Gallego Arias wrote:
>> As your example showed, current non-determinism in FLP doesn't
>> preserve program semantics in simple cases like:
>> coin = 0
>> coin = 1
>> let x = coin in (x,x)
>> !=
>> (coin,coin)
>> [Note that Sloth indeed can spot such simple cases and fix them, but
>> it doesn't work in general, with eta-expansion and so on.]
> Sorry, I don't understand that remark. Curry uses call-time choice
> which means that both expressions are not equal. I do not see what
> Sloth can do about this. The only option to make both expressions
> equal I see is using a run-time choice semantics. There may be good
> arguments for run-time choice, but it looks difficult to me to
> reconcile sharing with run-time choice.

Sorry I wasn't clear about that, when I speak about semantics I'm
referring just to denotational ones.

WRT Sloth operational behavior, what it does is simple common
expression elimination, so for the coin case you get

(coin,coin) is transformed to let M = coin in (M, M)

It is similar memoization, but just a hack and it doesn't work in a
lot of cases due to eta-expansion and so on. Also it has other side
effects, think of the infamous mono-morphism restriction.

Let's think for a moment that coin could be automatically transformed

coin = [0,1]

so then, in any sane semantics (both operational or denotational) the

let x = coin in (x,x) == (coin,coin)

does hold. This is the kind of treatment I'd like to have. I'm sorry I
haven't fully developed it yet.

One of the biggest points when selling declarative programming to the
students is the usual direct equivalence with mathematical structures,
like FOL in Prolog or functions in Haskell. We'd like to recover that
for Curry, so functions are functions again in the mathematical sense.a

>> We dislike semantics where this is not preserved, so perpetuating this
>> kind of behavior is not a path we'd like to follow,
> Are you asking for a change of Curry's semantics to use run-time choice
> instead of call-time choice?

No, I prefer call-time choice. I'm sorry I'm only working in
denotational semantics and I don't know yet which changes to the OS
would be needed.



curry mailing list
Received on Fr Mär 30 2007 - 13:30:23 CEST

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