From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id MAA18905; Fri, 5 Jul 2002 12:15:23 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id MAA19171 for ; Fri, 5 Jul 2002 12:15:23 +0200 (MET DST) Received: from relay.pair.com (relay1.pair.com [209.68.1.20]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g65AFLf15664 for ; Fri, 5 Jul 2002 12:15:21 +0200 (MET DST) Received: (qmail 69881 invoked from network); 5 Jul 2002 10:15:20 -0000 Received: from adsl-host-sf-228.apexworld.net (HELO checkerlap.d6.com) (66.114.212.228) by relay1.pair.com with SMTP; 5 Jul 2002 10:15:20 -0000 X-pair-Authenticated: 66.114.212.228 Message-Id: <4.3.2.7.2.20020705024112.038909f0@mail.d6.com> X-Sender: checker@mail.d6.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 05 Jul 2002 02:57:57 -0700 To: Xavier Leroy , Francois Pottier From: Chris Hecker Subject: Re: [Caml-list] Re: generic programming Cc: caml-list@inria.fr In-Reply-To: <20020705112551.B16273@pauillac.inria.fr> References: <20020705104249.B14853@pauillac.inria.fr> <200207030246.WAA28665@dewberry.cc.columbia.edu> <4.3.2.7.2.20020703102610.0248b280@mail.d6.com> <3D246739.4030204@ozemail.com.au> <20020705104249.B14853@pauillac.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk >Like Fran=E7ois, I find functional iterators so much cleaner >and better structured. Moreover, the extra "power" of imperative iterators >isn't obvious to me. I think this is a very important point, but I totally disagree with your=20 conclusion. Giving up explicit control over the flow of your program is a= =20 serious problem in my opinion, and callback solutions force you to do=20 that. Iterating over two things at once is an obvious example of where it= =20 breaks down, but it happens in a lot of places. Real closures make it less= =20 painful to deal with this than in languages without closures, because you=20 can have the map/iter code right there acting locally, but closures still=20 don't really eliminate the problem that you aren't in control of when that= =20 code gets called anymore. As another example, this idiom/pattern actually shows up a lot in GUI APIs= =20 for things like events. I think it's pretty clear at this point that=20 callback based event handling code leads to more lines of less readable and= =20 harder to understand code than having the client code be able to pull=20 things off a queue when it's ready for the events. I'm sure some disagree= =20 with this statement. Both of these are examples of "push versus pull" interfaces, and pull just= =20 seems to work better. Having data pushed at you means you often end up=20 buffering it on your end to manage your flow control anyway unless you're=20 just doing some trivial processing. Furthermore, it seems like it's a common trap to fall into saying the=20 familiar "you don't want to do that" (like your comment about hashtables)=20 when there's a fair amount of evidence that it's reasonable thing to want=20 to do (and I think better in a lot of ways). It seems like it's something= =20 a good language should support well. I'm not saying that callback/push interfaces are always bad, just that=20 there are strengths and weaknesses to both. To reference the XML thread,=20 there's a reason there are both DOM and SAX interfaces. I wish Ocaml=20 supported imperative/pull coding styles better, which is why I'm interested= =20 in this thread. It's late...hopefully this mail made some sense. Chris ------------------- 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