Browse thread
[Caml-list] Evaluation Order
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | John Max Skaller <skaller@o...> |
| Subject: | Re: [Caml-list] Evaluation Order |
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