Michael Hanus wrote:
> Wolfgang Lux wrote:
>> [...]
>> Moreover, the quote from the report is utterly misleading.
>> For instance, mapIO has result type IO [b], but its prelude
>> implementation is nevertheless flexible. And to add to the
>> confusion, sequenceIO is rigid whereas sequenceIO_ is not!
>> Therefore, I propose to simplify the default strategy so as
>> to make all functions flexible by default and replace the
>> quoted sentences by:
>>
>> A function can be explicitly annotated as rigid. If an
>> explicit annotation is not provided by the user, it is
>> flexible.
>
> These are good points and I agree to them.
> In the case of distributed programming mentioned above,
> the suspension is usually enforced by explicit rigid annotations
> or by rigidity of built-in functions like arithmetic or (==).
>
> A consequence of this proposal is the addition of some rigid
> annotations to IO actions in the prelude, but this is a minor task.
So which functions do you intend to make rigid? I guess, probably
putStr and browse. What about sequenceIO, sequenceIO_, mapIO, and
mapIO_? If you want to make the latter functions rigid, it does not
suffice to simply add an evaluation annotation, but you rather have
to unfold the foldr and map applications, or define rigid versions
of foldr and map. Neither of these alternatives looks really attractive
to me as it means code duplication, which is always error prone (just
consider the typical cut-and-paste definition of a rigid map
map_rigid eval rigid
map_rigid _ [] = []
map_rigid f (x:xs) = x : map f xs
with a subtle bug in it).
This makes me thinking that, the whole approach of evaluation
annotations is not flexible enough (pun intended). The nice
point about a HOT (higher-order [polymorphically] typed) language
is that we really do not need these annotations, but only a few
primitives. For instance, the only thing that we need in order to
define a rigid version of map is a simple function
rigidSpine :: [a] -> [a]
which (lazily!) ensures that the spine of its result list is
instantiated. With the help of this function, map_rigid can
now be defined as
map_rigid f = map f . rigidSpine
Now it is also straight forward to make mapIO_, sequenceIO_, etc.
rigid. However, I'm not sure whether these function should be
really defined rigidly, or whether it is better to leave it to
the user to insert applications of rigidSpine at appropriate
places.
Interestingly, it is very simple to define rigidSpine in Curry
without any evaluation annotation.
rigidSpine xs =
case xs of
[] -> []
(x:xs) -> x : rigidSpine xs
does the job. Eventually, you are unhappy about the fact that
this relies on case expressions being matched rigidly. Therefore,
I propose the addition of a single new primitive function
rigid :: a -> a
which is equivalent to the identity function except that it
suspends until its result is instantiated to a non-variable
term. [Incidentally, even this function can be defined in
Curry already:
rigid x = x `seq` x
This definitions make use of the fact that seq is rigid in its
first argument. However, I'm not sure whether making seq rigid
eventually was another ill-advised suggestion by me.]
So my conclusion is that we do not need evaluation annotations
except for committed choice(*), but rather a single new
primitive function rigid, which allows for a much more flexible
implementation of communications patterns.
Regards
Wolfgang
(*) Probably, one does not need them for committed choice either.
Looking at the FlatCurry module, I see that PAKCS translates
functions defined with committed choice into applications of
the primitive function prelude.commit. So one could get rid
of evaluation annotations altogether (which has the nice effect
of giving the keyword eval back to the user -- I did more than
once define a function eval only in order to be reminded by the
compiler that this is not an identifier) by making this function
public.
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Do Nov 04 2004 - 09:44:46 CET