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 VAA28571; Fri, 5 Jul 2002 21:31:26 +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 VAA28450 for ; Fri, 5 Jul 2002 21:31:25 +0200 (MET DST) Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.25.148.40]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g65JVMf08240; Fri, 5 Jul 2002 21:31:22 +0200 (MET DST) Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id g65JVFSs012855; Sat, 6 Jul 2002 05:31:15 +1000 (EST) Received: from ozemail.com.au (ppp141.dyn18.pacific.net.au [61.8.18.141]) by wisma.pacific.net.au with ESMTP id FAA08645; Sat, 6 Jul 2002 05:31:13 +1000 (EST) Message-ID: <3D25F400.6090703@ozemail.com.au> Date: Sat, 06 Jul 2002 05:31:12 +1000 From: John Max Skaller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: Chris Hecker CC: Xavier Leroy , Francois Pottier , caml-list@inria.fr Subject: Re: [Caml-list] Re: generic programming 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> <4.3.2.7.2.20020705024112.038909f0@mail.d6.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Chris Hecker wrote: > > Both of these are examples of "push versus pull" interfaces, and pull > just seems to work better. Having data pushed at you means you often > end up buffering it on your end to manage your flow control anyway > unless you're just doing some trivial processing. This was once explained to me really well, I can't hope to give as good an explanation as I was given, but I'll try: the reason 'pull' is better is that the natural place to put your state data is 'on the stack' and the most important case of this data is the program counter. Put another way, your location in the code is the best way to encode the configuration of your state data, which has something to do with the naturalness of block structured programming: when you are 'here' in the code, 'these' variables are visible and contain the state. > I'm not saying that callback/push interfaces are always bad, What Francois Pottier said is correct, IMHO: callbacks are best in simple cases, in particular, when there is NO state, using them clearly makes the simple structure of your code evident in the syntax. Callbacks are *also* probably best when the problem is extremely complex. But 'pull' interfaces shine when there is a natural heirarchical decomposition which can be readily represented by putting all your state data on the machine stack, and encoding the 'variant tag' of the union of all stack states in the natural place -- the program counter. So: when you don't need state data, the stack doesn't help, you might as well use a callback. And when the problem is really complex, you might as well put all your data into an object, and drive the system as a state machine: this is better than mixing up the explicit and implicit state in an arbitrary way (some on the stack, some in a state object ..) In between, there is a large class of tree structured problems that admit a clean solution using subroutines and local variables. Classic example: recursive descent parser. Classic counter example: Earley parser (needs frames threaded in two distinct ways, to allow one to go back and try again after success as well as failure). heh. It is interesting that Ocaml experts are arguing for functional iterators -- which in fact amount to 'goto' programming, whilst the 'pull' interface is the essence of functional decomposition :-) The power and utility of the machine stack is hard to deny -- it is important enough that hardward provides it :-) -- John Max Skaller, mailto:skaller@ozemail.com.au snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia. voice:61-2-9660-0850 ------------------- 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