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
mail).
Regards
Wolfgang
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Fr Nov 09 2007 - 17:51:51 CET