From: Patrick M Doane <patrick@watson.org>
To: Chris Hecker <checker@d6.com>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] two unrelated questions
Date: Wed, 25 Apr 2001 20:38:43 -0400 (EDT) [thread overview]
Message-ID: <Pine.BSF.3.96.1010425202832.44330B-100000@fledge.watson.org> (raw)
In-Reply-To: <200104252108.OAA02055@smtp2-cm.mail.eni.net>
On Wed, 25 Apr 2001, Chris Hecker wrote:
>
> 1. What is the right "functional pattern" for early-outing on success
> while using an iter/map/fold type function? Say I'm using iter to
> search for something in an opaque datastructure. Should I throw
> an exception to get out, or is that bad style? I guess this
> question only makes sense for iter, since map/fold produce results
> that you theoretically want to preserve. So, the question is
> really, given an iter-style interface to a datastructure (one that
> takes an ('a -> unit)), how do you tell it to stop iterating? I
> guess if the function was ('a -> bool) you could do it that way,
> but most iters aren't ((List|Array|Hashtbl).iter, for example).
> Is throwing an exception the best bet?
>
One way to think about exceptions is to treat them simply as control flow
expressions. For example, the 'break' statement is used in C/C++ to
early-out of iteration constructs. This translates naturally to
exceptions:
exception Break
try
List.iter (fun .. -> ... raise Break) l
with Break -> ()
We can even get labelled breaks like Java:
exception Break of string
try
List.iter (fun ... ->
try
List.iter (fun ... ->
if .. then raise (Break "inner")
else raise (Break "outer")
) list1
with Break "inner" -> ()
) list2
with Break "outer" -> ()
I personally don't think this is bad style but others may have a different
opinion.
It also seems that the overhead for a try block in Caml is relatively low,
but I've never looked too much at the compiled code to see what it is
doing.
Patrick
-------------------
To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr
next prev parent reply other threads:[~2001-04-26 0:40 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-25 21:08 Chris Hecker
2001-04-26 0:38 ` Patrick M Doane [this message]
2001-04-26 6:04 ` Judicaël Courant
2001-04-26 12:06 ` John Max Skaller
2001-04-27 9:12 ` Anton Moscal
2001-04-29 22:24 ` Brian Rogoff
2001-04-30 18:57 ` Fergus Henderson
2001-05-01 1:31 ` Jacques Garrigue
2001-05-01 12:45 ` [Caml-list] " Ken Friis Larsen
2001-04-27 15:09 ` [Caml-list] " Brian Rogoff
2001-04-27 17:49 ` John Max Skaller
2001-04-26 8:22 ` Andreas Rossberg
2001-04-26 1:13 ` Jacques Garrigue
2001-04-26 13:47 ` Xavier Leroy
2001-04-26 22:34 ` Chris Hecker
2001-04-26 16:57 ` Mark Seaborn
2001-04-26 22:20 ` John Max Skaller
2001-05-01 21:08 ` Brian Rogoff
2001-05-01 23:30 ` John Max Skaller
2001-05-02 0:03 ` John Max Skaller
2001-05-01 17:25 Dave Berry
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=Pine.BSF.3.96.1010425202832.44330B-100000@fledge.watson.org \
--to=patrick@watson.org \
--cc=caml-list@inria.fr \
--cc=checker@d6.com \
/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