Re: Return type of procedures?

["David McClain" <dmcclain@azstarnet.com>]

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 <skaller@maxtal.com.au>
To: caml-list@inria.fr <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
>