From: Alain Frisch <Alain.Frisch@inria.fr>
To: Raj B <rajb@rice.edu>
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Generators/iterators and lazy evaluation?
Date: Wed, 04 Apr 2007 22:46:45 +0200 [thread overview]
Message-ID: <46140EB5.50700@inria.fr> (raw)
In-Reply-To: <CCF54B6E-E0E6-48B3-93A2-458FFF5FD769@rice.edu>
Raj B wrote:
> The 'yield' statement is the point where the function returns the next
> value and suspends itself until the next time it is 'forced'. At that
> time it resumes execution where it left off.
>
> OCaml makes this particularly hard to implement this due to lack of
> 'control flow' features, including even a call/cc. The only way I can
> see right now is breaking this code down into little functions, saving
> the current execution environment during the suspend and keeping track
> of the right function to call the next time.
>
> I've been thinking about whether I can express this in some elegant way
> in some lazy construct in OCaml, since this is basically a form of
> 'lazy' evaluation.
I think you cannot implement this notion of iterator without some kind
of control flow operator (at runtime) or some code rearrangement (at
compile time). The point is that you must mainting several active
"threads" of computations, including their own stack.
A natural solution, as you suggest, is to write your interpreter in
continuation-passing style. This should not be too hard, and will
actually make your source-level interpreter look more like a bytecode
interpreter (especially if you additionnaly defunctionalize the
interpreter, see:
http://www.brics.dk/RS/03/Abs/BRICS-RS-03-Abs/BRICS-RS-03-Abs.html#BRICS-RS-03-14
). Btw, a related solution is to push the idea and write a real bytecode
interpreter.
Another approach would be to use an implementation of control
operators for OCaml. AFAIK, they exist only in bytecode (
http://caml.inria.fr/pub/ml-archives/caml-list/2006/02/8fc9c1a56c497b9743515a5e3432d704.en.html
).
Yet another solution would be to rely on OCaml threads (but that will
probably be inefficient and not very pretty).
-- Alain
next prev parent reply other threads:[~2007-04-04 20:46 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-04 16:33 Raj B
2007-04-04 20:10 ` [Caml-list] " Mathias Kende
2007-04-04 20:46 ` Alain Frisch [this message]
2007-04-04 21:16 ` Erik de Castro Lopo
2007-04-04 21:37 ` Erik de Castro Lopo
2007-04-04 22:55 ` Bill Wood
2007-04-05 2:49 ` skaller
2007-04-05 16:41 ` Richard Jones
2007-04-04 23:53 ` Jon Harrop
2007-04-05 3:13 ` Erik de Castro Lopo
2007-04-05 5:58 ` Alain Frisch
2007-04-05 20:35 ` Jon Harrop
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=46140EB5.50700@inria.fr \
--to=alain.frisch@inria.fr \
--cc=caml-list@yquem.inria.fr \
--cc=rajb@rice.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