From: Alessandro Baretta <alex@baretta.com>
To: "Michaël Grünewald" <michael-grunewald@wanadoo.fr>,
Ocaml <caml-list@inria.fr>, Pixel <pixel@mandrakesoft.com>
Subject: Re: [Caml-list] Re: Wasn't O'Caml a functional language?
Date: Tue, 24 Sep 2002 10:45:49 +0200 [thread overview]
Message-ID: <3D90263D.2010706@baretta.com> (raw)
In-Reply-To: <871y7m1wlv.fsf@ketanu.dyndns.org>
Michaël Grünewald wrote:
> Alessandro Baretta <alex@baretta.com> writes:
>
>>Anyway, my main claim, although misdirected, in not entirely
>>faulty. Queue.transfer can be thought of as analogous to
>>List.append. When I write let list = list1 @ list2 I do not expect
>>side-effects on list1 or list2.
>
>
> Then you maybe should use Lists, why, if queues have the same behavior than
> lists, give them a different name ?
They don't have the same behavior, and are not supposed to
have the same behaviour.
let l = [] in
let l = e1 :: l in
let l = e2 :: l in
let l = e3 :: l in
List.iter f l
is equivalent to
f e3; f e2; fe1
which is not what I need. On the other hand,
let q = Queue.create () in
let _ = Queue.add e1 q in
let _ = Queue.add e2 q in
let _ = Queue.add e3 q in
Queue.iter f q
is equivalent to
f e1; f e2; f e3
which is correct with respect to what I need. This is the
reason for using Queues. I somehow expected this to be the
only difference with respect to Lists, and did not suspect
that some of the functions of the Queue module (other than
the obvious add and take) had side-effects. I realize that
"transfer" is a significantly different name than "append",
and I should have known better than to use it without
expecting side-effects, but, anyway, I was stumbled on this
function. And, believe me, it took me quite a while to
figure out in Ocamldebug/Epeire why in the world my program
was doing what it was. So let me say, "Long live functional
iterators which have no side-effects! Down with explicit
handling of aliasing! " [ ... feel free to add here whatever
political slogans you like best ;) ]
BTW, picking up on Pixel's comment, I don't really know
whether Queues are any more efficient than
lists-used-as-FIFO, although I would expect them to be. I am
mostly interested in the conciseness of the API.
Queue.iter f q
is much more elegant and readable than the equivalent
List.iter f (List.rev l)
Of course, performance is also important, but the software
I'm writing will have its bottleneck in IO anyway, so no
there is no significant advantage to be had by optimising
the algorithms, other than to increase the fraction of CPU
idle time, which is already pretty high. Of course, in other
contexts, performace would matter a lot more.
Cheers,
Alex
-------------------
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-09-24 8:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-21 22:47 [Caml-list] " Alessandro Baretta
[not found] ` <15756.65084.40025.869484@spike.artisan.com>
2002-09-21 23:47 ` Alessandro Baretta
2002-09-22 4:23 ` [Caml-list] " Michaël Grünewald
2002-09-23 10:40 ` Pixel
2002-09-24 8:45 ` Alessandro Baretta [this message]
[not found] ` <15760.15527.648990.807473@hod.void.org>
2002-09-24 13:32 ` Alessandro Baretta
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=3D90263D.2010706@baretta.com \
--to=alex@baretta.com \
--cc=caml-list@inria.fr \
--cc=michael-grunewald@wanadoo.fr \
--cc=pixel@mandrakesoft.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;
as well as URLs for NNTP newsgroup(s).