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 JAA10181 for caml-red; Tue, 22 Aug 2000 09:48:05 +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 XAA04839 for ; Mon, 21 Aug 2000 23:56:16 +0200 (MET DST) Received: from cepheus.azstarnet.com (cepheus.azstarnet.com [169.197.56.195]) by concorde.inria.fr (8.10.0/8.10.0) with ESMTP id e7LLuFf21025 for ; Mon, 21 Aug 2000 23:56:15 +0200 (MET DST) Received: from dylan (dialup19ip054.tus.azstarnet.com [169.197.39.54]) by cepheus.azstarnet.com (8.9.3/8.9.3) with SMTP id OAA25892 for ; Mon, 21 Aug 2000 14:56:11 -0700 (MST) X-Sent-via: StarNet http://www.azstarnet.com/ Message-ID: <002401c00bba$f9ee4ae0$210148bf@dylan> From: "David McClain" To: Subject: Re: Return type of procedures? Date: Mon, 21 Aug 2000 14:58:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: weis@pauillac.inria.fr Is it just me? I am quite troubled by the concepts you propose in a new language. You chose to use Caml for very good reasons. Why would you do away with things like immutable global environments for your users? Procedures altering the environment in such a way as to cause a function to behave differently on separate invocations seems like it is going against the basic tenets of FP. The FP approach makes it so easy to reason about the behavior of programs. Partial evaluation allows customization of functions when needed. Am I missing something here? - David McClain, Sr. Scientist, Raytheon Systems Co., Tucson, AZ -----Original Message----- From: John Max Skaller To: caml-list@inria.fr Date: Monday, August 21, 2000 2:33 PM Subject: Return type of procedures? >I am designing a programming language (the compiler is written >in ocaml) which is a procedural language with 'purely functional' >expressions (using eager evaluation). Function closures can >access their context, which procedural statements my change between >building the closure and evaulating it. Procedural closures may >mutate their environment. > >Procedures and functions are defined with distinct keywords >'procedure' and 'function'. I have given a procedure the >functional type > > 'a -> unit (where 'a may sensibly be 'unit') > >whereas functions have signature > > 'a -> 'b > >where either 'a or 'b may be unit. Note that if 'a is unit, the >function is not necessarily constant, since it may depend on >the environment. OTOH, a function with 'b as unit is farily >useless. > >However, as it stands, the type system fails to achieve >separation of functions and procedures: > > procedure p: unit -> unit > function f: unit -> unit > f (p ()) // woops! > >Here is an expression (functional code) which has taken the result >of calling a procedure (unit) as an argument. > >Proposal: just as unit is the trivial product (tuple, terminal object), >so >we say 'void' is the trivial sum (initial object), and make procedures >have the signature > > procedure f: unit -> void > >Now, procedures cannot be used 'in' expressions anywhere, >provided we do not allow the argument of a function or procedure >to have 'void' type. We can also treat procedures uniformly >from a typing view point. > >Comments? > > >-- >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 >