Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Python's yield, Lisp's call-cc or C's setjmp/longjmp in OCaml
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Nuutti Kotivuori <naked+caml@n...>
Subject: Re: [Caml-list] Python's yield, Lisp's call-cc or C's setjmp/longjmp in OCaml
I'm answering to all of this with a single reply.

ijtrotts@ucdavis.edu wrote:

[...]

> Why not do this:

[...]

Falk Hueffner wrote:
> This only works for simple examples. Try for example writing a
> function which successively yields all possible moves for a chess
> board. The "yield" operator really helps there.

Pierre Weis wrote:
> Very interesting: please give us the code corresponding to this
> example, in order for us to realize how the full power of the
> "yield" operator helps to solve this problem.

David Brown wrote:
> The icon language has been around with a similar operator for quite
> a while.  It is very useful for prolog-type backtracking, since the
> code can be written fairly naturally.
>
> However, this construct is fairly easy to implement in regular
> OCaml.

brogoff@speakeasy.net wrote:
> While I think yield is pretty cool, having used in Sather, which got
> in from CLU I believe,you can simulate this control flow and more
> using higher order functions. Sticking with the simple example, but
> ditching the array and rolling my own streams with core ML yields
> (ha!)

[...]

> In any case, programming this kind of thing in ML is pretty easy, so
> I don't think we need an extension to the language for yield. callcc
> is more powerful, but I don't like the possibility that making
> callcc fast penalizes code which doesn't use it. We have exceptions
> and threads already.

I guess the main point about all this is that there are situations
where having first-class continuations, or being able to yield, leads
to code that is more natural.

OCaml is a nice language with plenty of choices for using streams,
higher order functions, threads and the like to achieve the same
effect, so there certainly is no burning need for the features.

I found a nice paper on the usage of call/cc, that explains
coroutines, re-entry and multitasking implemented with that. It's
here:

  http://lambda.weblogs.com/discuss/msgReader$3056

A personal example of what I am thinking of would be to have a long
function which does a lot of stuff, but requires some external input
at times - and it would be nice if the system would just suspend the
evaluation until that input comes available.

Now I can think of several ways to do this.

I could just split the function into several parts, and have them get
a state as a parameter that's returned from the previous function and
given to the next - and the state holds all the context required for
it. Or have an object do the same thing.

I could have it all in one function, but have the function return
closures for the rest of the code, with the wanted input being the
parameter of. That is, simply nesting the functions - then the state
is carried in the local environment of the functions.

I could have it as a separate thread, blocking on input from an event
channel, and that channel would be fed the external inputs when they
become available.

And a whole bunch of more things - but the most natural way would be
just write it all in one function, straight through, with a call that
could be used for fetching the inputs when they become
available. Going for the separate thread model makes the resulting
code look just the same, since it would be a blocking call only, and
this would look like a blocking call - but the thread produces a whole
lot of other issues.

Now, I can do this with call/cc - and I can do it with yield, albeit
clumsily - and I can do it with setjmp/longjmp. Hence my question.

For my part, my curiosity is fulfilled - I will just work around the
issues. If someone is implementing something allowing this into OCaml,
my curiosity rises again :)

Thanks for all the replies, they were very helpful.
-- Naked

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners