From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA06181 for caml-red; Thu, 24 Aug 2000 10:01:34 +0200 (MET DST) 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 UAA00433 for ; Wed, 23 Aug 2000 20:42:35 +0200 (MET DST) Received: from localhost.localdomain (ike76.zip.com.au [210.23.146.76]) by concorde.inria.fr (8.10.0/8.10.0) with ESMTP id e7NIgUD23280 for ; Wed, 23 Aug 2000 20:42:31 +0200 (MET DST) Received: from maxtal.com.au (IDENT:root@localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.8.7) with ESMTP id PAA18394; Wed, 23 Aug 2000 15:55:36 +1000 Message-ID: <39A36758.E474CC1E@maxtal.com.au> Date: Wed, 23 Aug 2000 15:55:36 +1000 From: John Max Skaller X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: David McClain CC: caml-list@inria.fr Subject: Re: Language Design References: <000d01c00bb8$fb3e3560$210148bf@dylan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: weis@pauillac.inria.fr David McClain wrote: > I, for one, have fought for many years with languages that insisted on a > division between functions and procedures as you describe them. I have found > the unified "everything is a function" approach to be most appealing. In > particular, the worst offenders are those languages that insist on syntactic > distinctions such as Fortran, RSI/IDL, and Basic. I cannot be alone in > having difficulty remembering when a routine, whose result I don't really > need, is to be called as a function, or as a procedure. There are two reasons for the distinction. The crucial one is this: my translator performs an operation called 'control inversion', in which a primitive 'read x', which reads input, is implemented by returning a continuation, that is, by yielding control and waiting until the input is available. Any procedure containing a read (directly or indirectly on the call chain) must also return a continuation (which is immediately invoked) so that the dynamic call chain is not represented on the machine stack. This technique allows a dispatcher to _call_ the program with messages, that is, it translates an algorithmic form of the code into an event driven form. This allows a program handling millions of instances of something (telephone calls in my case), to dispatch in log n time (amortised constant time in fact), rather than the linear time required for OS threads. [the alternative, writing event driven code, is a severe regression back to the bad old days of totally unstructured coding] On the other hand, returning continuations has a high constant time overhead. To solve this problem, purely functional code is executed using the machine stack. The second reason for the distinction is the 'usual' one: purely functional code has a useful property, namely referential transparency. [Technically, the identification of 'needs to be control inverted' with 'procedure' is incorrect: only some procedures can lead to elaboration of the read primitive: I plan to handle this later by analysis and optimisation, but without a further distinction in the procedure type, this analysis cannot cross compilation unit boundaries, and I suspect that users will be less than happy with two kinds of procedures as well as functions :-] What is _actually_ required is a seamless way to integrate stateful and function code: the recent (obvious :-) discovery that the basic duality principle of category theory when applied to functional theory yields a stateful theory promises to yield significant progress in the near future. But this is too cutting edge for me to try for in what my employer thinks is a simple 4GL for handling telephone calls. :-) -- John (Max) Skaller, mailto:skaller@maxtal.com.au 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850 checkout Vyper http://Vyper.sourceforge.net download Interscript http://Interscript.sourceforge.net