Re: Intended meaning

From: Wolfgang Lux <>
Date: Fri, 09 Nov 2007 17:10:10 +0100

Bernd Brassel wrote:

> One point to remark is that it is not feasible to execute
> steps 3 and 4 if your integers are solely given in a primitive way.
> You
> would have to "narrow" to (0?1?-1?2?-2?...) Do you want to do this for
> functions "f 1 = success" and "g 0 = success"? I am asking this
> because
> it directly relates to your problem as one of the very main reasons to
> have residuation as a language construct is the existence of types
> like integers.

But this is only *one* of the main reasons. The other is to support
synchronization of threads in (and-)parallel computations.

> Therefore I see two solutions to this:
> a) allow residuation only on such built-in types, e.g., have functions
> "ensureInt :: Int -> Int " and
> "ensureFloat :: Float -> Float"
> "ensureIOHandle :: IOHandle -> IOHandle"
> and then live with the incompleteness for such types.

It looks somewhat arbitrary to me to restrict residuation to primitive
types as it rules out some reasonable uses of algebraic data types as
passive constraints. Think of Port constraints where the reader of a
port is synchronized by the message list becoming instantiated when new
data is written to the port.

> b) suspend also on non-deterministic choices, e.g.
>> 3. ... g (True ? False)
> does not evaluate any further as g is rigid.

This will not help at all. Note that the problem is caused by
instantiating the variable in *other* parts of the program, so --
depending on the implementation -- g may not be aware of the
non-determinism in its argument. Furthermore, the problem occurs
even if g's argument is deterministic (see my answer to Sergio's


curry mailing list
Received on Fr Nov 09 2007 - 17:51:51 CET

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