Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Nuutti Kotivuori <naked+caml@naked.iki.fi>
To: ijtrotts@ucdavis.edu
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Python's yield, Lisp's call-cc or C's setjmp/longjmp in OCaml
Date: Thu, 18 Dec 2003 02:51:12 +0200	[thread overview]
Message-ID: <87zndrq77j.fsf@naked.iki.fi> (raw)
In-Reply-To: <200312162230.23322.ijtrotts@ucdavis.edu> (ijtrotts@ucdavis.edu's message of "Tue, 16 Dec 2003 22:30:23 -0800")

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


  parent reply	other threads:[~2003-12-18  0:51 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-16 13:13 Nuutti Kotivuori
2003-12-16 13:28 ` Oleg Trott
2003-12-18  0:15   ` Nuutti Kotivuori
2003-12-16 13:48 ` Ville-Pertti Keinonen
2003-12-16 15:41   ` Kenneth Knowles
2003-12-16 16:45     ` Richard Jones
2003-12-16 18:36       ` Ville-Pertti Keinonen
2003-12-16 18:42 ` Brian Hurt
2003-12-16 18:10   ` Dustin Sallings
2003-12-17  6:30     ` ijtrotts
2003-12-17  8:13       ` Dustin Sallings
2003-12-17 10:35       ` Falk Hueffner
2003-12-17 19:14         ` Pierre Weis
2003-12-17 19:32           ` Falk Hueffner
2003-12-17 20:04           ` David Brown
2003-12-18  1:14           ` Nicolas Cannasse
2003-12-18  5:31             ` David Brown
2003-12-18  7:05             ` Brian Hurt
2003-12-18  6:45               ` David Brown
2003-12-18 18:44             ` brogoff
2003-12-17 19:42         ` brogoff
2003-12-19 13:39           ` skaller
2003-12-18  0:51       ` Nuutti Kotivuori [this message]
2003-12-16 18:06 Kevin S. Millikin
2003-12-18 22:08 Ker Lutyn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zndrq77j.fsf@naked.iki.fi \
    --to=naked+caml@naked.iki.fi \
    --cc=caml-list@inria.fr \
    --cc=ijtrotts@ucdavis.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox