Re: [Caml-list] Evaluation Order

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

Dave Mason wrote:

> > In principle, the Felix type checker would prevent this:
> > side-effects are not permitted in functions.
> 
> >       The reason for relaxing the rules is that it is very ugly and
> > insecure to write things like:
> 
> >       val x : int; // uninitialised variable!
> >       fetch(&x,&state_object);
> 
> > instead of
> 
> >       val x : int = fetch(&state_object);
> 
> > I can't think of good way around this though.
 
> Functions *should* be able to do side-effects (unless you have a pure
> functional language), 

	My desire is to have a purely functional subsystem.
So I would 'say' that functions cannot have side effects.
However, Felix has procedures too, which cannot return
values. There is a reason for this.

	Functions execute 'on the stack'. They may not
read input or have any side effects.

	Procedures work by continuation passing.
When you call a procedure, it _returns_ control,
passing a continuation, which is immediately
resumed by the driver. When a request to read input
is encountered, control is also returned.
The driver then stores a message and resumes
the continuation. In other words, the system
is event driven transparently.

	Now see below:

> I think my proposal from the weekend is better: functions can have
> side effects, but you can't use the results in a way that will bite
> you (due to order of evaluation).

	That is what I am looking for. Basically,
I want some sugar, so that users can write:

	val x = f();

but the implementation is actually equivalent to:

	val x;
	f(&x); 

Note that this is implemented like this:

	switch(pc) {
	...
	...
	pc = 2;
	return new f(&x);
	case 2:
	...

So in Felix, it is not a matter of style that procedures
returning values cannot be used 'inside' expressions:
it would greatly complicate the compiler, because it
would have to linearise expression trees 'down to'
any procedure call. Currently, expressions are 
simply replaced by their C++ equivalents, and the C++
compiler can then have a go at optimising them.

BTW: I'm currently putting Felix up on sourceforge:

	http://felix.sf.net

-- 
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
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr