Re: Language Design

[John Max Skaller <skaller@maxtal.com.au>]

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