Re: [Caml-list] environment idiom

[skaller <skaller@users.sourceforge.net>]

On Mon, 2004-12-13 at 17:18, skaller wrote:

BTW: one reason I'm very interested in the 'transparency'
and 'purity' topic is a practical matter:

> Another example is my Felix language. It has both functions
> and procedures. Functions aren't allowed to have side effects,
> yet they're not pure in the sense the result can depend
> on variables which change between (but not during) invocations.
> [This has an alarming effect on the optimiser ..]


Crudely the optimiser simply inlines everything,
perhaps an improved version will do usage checks
to cache results..

This must work fine if functions are pure.
But as noted, they're not, because they can access variables
that change with time, and so the place of calling a
function, which is related to when it is evaluated,
makes a difference.

To fix this I need to be able to do something crude
like designate a function as 'pure' -- this has been
discussed for Ocaml too.

That isn't the only possible technique, and it isn't
clear how to carry this information through for
function variables, unless the type system is involved.
EG you have two arrows:

	a -> b  pure function
	a +> b  can refer to variables

which raises questions about unification, overloading,
subtyping, etc.

However if a function isn't pure, when you evaluate
it matters .. but that doesn't tell you when to evaluate it.
Instead of saying 'strict' or 'lazy', one could annotate
function arguments:

	let f (g:lazy) (h:eager) (k:pure) x  = ..

which tells the compiler that to evaluate h 'before
the call', g precisely when needed, possibly twice
with different results, and k anytime convenient.
 
Well that seems to impact the type system too.. :)

At present I use a trick to distinguish procedures:
they have the type

	'a -> void

which prevents them being used in a context where
the sequence of evaluation is indeterminate (i.e. in
expressions). 

Well now I seem to need more than just procedures
and functions, I need at least pure and impure
functions (where impure does NOT mean side-effects,
but rather non-parametricity, which has the same
negative effect on transparency).

So I have a pragmatic interest in finding a theoretical model
that says something more about how pure/impure/lazy/eager/etc etc
code interacts: with the optimiser switched on, I'm the only
person that can predict what a Felix program will do,
and my own optimiser has caught me out several times already :)


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net