From: John Prevost <visigoth@cs.cmu.edu>
To: OCaml Mailing list <caml-list@inria.fr>
Subject: Re: [Caml-list] Breaking out of iterative loops
Date: 01 May 2002 22:18:07 -0400 [thread overview]
Message-ID: <863cxbmgww.fsf@laurelin.dementia.org> (raw)
In-Reply-To: <3CD08EE3.9010202@ozemail.com.au>
>>>>> "js" == John Max Skaller <skaller@ozemail.com.au> writes:
js> the particular example that bugs me the most is this one:
js> List.fold_left (&&) true (List.map2 pred a b)
js> What is the input data were infinite? Hmmm .. in an eager
js> language, the usual functional decomposition is useless.
js> CPS is looking better every day :-)
Another way to handle this is to use a datastructure that's meant to
work in this situation, rather than lists. (To be honest, I somewhat
dislike the ability to define recursive datastructures in O'Caml for
this reason.)
module Stream =
struct
type 'a t = unit -> 'a cell
and 'a cell = Nil | Cons of 'a * 'a t
let decons s = s ()
let cons h t = fun () -> Cons (h, t)
let rec append a b = fun () ->
match decons a with
| Nil -> decons b
| Cons (h, t) -> Cons (h, append t b)
let rec map f l = fun () ->
match decons l with
| Nil -> Nil
| Cons (h, t) -> Cons (f h, map f t)
(* ... etc ... *)
end
A smarter implementation (I just threw this off the top of my head)
would include remembering already accessed values and the like (lazy
evaluation). With such a data structure, designed for infinities,
processing infinite values is easier.
The drawback to allowing:
let rec ones = 1 :: ones
and such expressions is that when looking at the definition of, for
example, 'a list and length, one would expect it to be guaranteed that
length terminates. Since you can't prevent recursive use of
constructors, well, you can no longer guarantee that.
John.
-------------------
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
next prev parent reply other threads:[~2002-05-02 6:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-30 20:27 Vincent Foley
2002-04-30 21:38 ` Johan Baltié
2002-05-02 0:57 ` John Max Skaller
2002-05-02 2:18 ` John Prevost [this message]
2002-05-02 8:33 ` Markus Mottl
2002-05-02 9:14 ` Francois Pottier
2002-05-02 9:50 ` Alain Frisch
2002-05-02 14:35 ` Alessandro Baretta
2002-05-02 15:40 ` John Max Skaller
2002-05-02 13:15 Krishnaswami, Neel
2002-05-02 13:34 ` Markus Mottl
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=863cxbmgww.fsf@laurelin.dementia.org \
--to=visigoth@cs.cmu.edu \
--cc=caml-list@inria.fr \
/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;
as well as URLs for NNTP newsgroup(s).