From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id BAA14805; Thu, 18 Dec 2003 01:51:23 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id BAA14465 for ; Thu, 18 Dec 2003 01:51:22 +0100 (MET) Received: from smtp1.pp.htv.fi (smtp1.pp.htv.fi [212.90.64.119]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id hBI0pHX21565 for ; Thu, 18 Dec 2003 01:51:18 +0100 (MET) Received: from posti.pp.htv.fi (posti.pp.htv.fi [212.90.64.50]) by smtp1.pp.htv.fi (Postfix) with ESMTP id 171DC80C10; Thu, 18 Dec 2003 02:51:14 +0200 (EET) Received: from oro (aka.pp.htv.fi [213.243.183.115]) by posti.pp.htv.fi (8.11.1 (Revision 1.5+JAGae91741+JAGae92668) /8.11.1) with ESMTP id hBI0pCT29990; Thu, 18 Dec 2003 02:51:13 +0200 (EET) Received: from naked by oro with local (Exim 3.36 #1 (Debian)) id 1AWmNk-0002Pv-00; Thu, 18 Dec 2003 02:51:12 +0200 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 References: <203E10E3-2FF3-11D8-A94A-000393CFE6B8@spy.net> <200312162230.23322.ijtrotts@ucdavis.edu> From: Nuutti Kotivuori Date: Thu, 18 Dec 2003 02:51:12 +0200 In-Reply-To: <200312162230.23322.ijtrotts@ucdavis.edu> (ijtrotts@ucdavis.edu's message of "Tue, 16 Dec 2003 22:30:23 -0800") Message-ID: <87zndrq77j.fsf@naked.iki.fi> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 python's:01 lisp's:01 c's:01 ijtrotts:01 falk:01 hueffner:01 pierre:01 weis:01 brogoff:01 clu:99 callcc:01 callcc:01 threads:01 threads:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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