caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
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


  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).