On 15/02/2014, at 9:33 AM, Martin DeMello wrote:
> It would have to be a generator whatever you do (other than pass in an error
> closure, I guess, but I personally don't like that)
Why not?
Exceptions as in C++ are seriously bugged, because the caller
has to set up a handler for the expected error, but there's
no way to really know what that is.
But what we do have is that there are (at least) two control
flows out of the called procedure into the caller, the
normal one and the error one. The control paths are
set up inside the caller, but the decision is made in the
callee.
So the responsibility is on the caller to provide
the normal and abnormal actions, and the choice
on the callee.
Now if you take a continuation passing viewpoint,
the caller is required to pass two continuations
to the subroutine:
the normal continuation
an abnormal continuation
and of course subroutine calling as we know it passes a continuation
by pushing the program counter onto the machine stack.
So it seems reasonable to pass the abnormal continuation to
the subroutine .. the REAL problem is that the syntax for normal
continuation is seriously limited, because it's implicit.
the syntax we'd have to use is a normal function call with
an extra argument ..
Now I proposed passing a closure containing a goto.
At least one advantage is that you can't actually forget!
And if that closure takes an argument with details of
the kind of error, even better, because then the type system
helps ensure you provide the right kind of handler.
Right now, Felix has another way to do this too: it now has
computed gotos. So you could actually pass a label instead
of a closure and the subroutine could jump to it. (but the label
actually has a closure attached so its similar).
Any-which-way you look at it, passing the error handler down
to the subroutine makes sense because it ensures a connect
between the throwing of the error and the handler .. just as
"subroutine call" ensures that the normal continuation is at
the point just after the call.
Anyhow roughly the only good solution to this is to get
rid of the whole idea of subroutines and mandate explicit
continuation passing. Once we can have a good way to do that
the normal and abnormal continuations has the same status.
So there's really no problem handling errors .. the problem
is that NORMAL control flow is bugged by constraining it
to subroutine calling.
I can actually demonstrate this using an apparently unrelated Felix
technology: fibres and channels.
proc dosomething (
input: schannel[T],
normal:schannel[U],
error:schannel[E]
) {
var i = read input; // get argument
do-some-calculations;
if we got an error do
write (error, errorcode);
else
write (normal, result);
done
}
So now, this is vastly superior to a subroutine! The handling of the normal
and error conditions is symmetric.
So how do you use it?
Simple. You HAVE to spawn three fibres:
spawn_fibre { dosometing (input, normal, error); };
spawn_fibre { var code = read error; .. };
spawn_fibre { var good = read normal; ... }
The first fibre does the calculation and writes the answer on the normal
channel,
unless there's a problem, then it writes the error on the error channel.
The error channel sends the code to the error handler fibre,
and the normal channel to the normal handler.
This is just VASTLY superior to anything else. Why? For a start, the error
handler
can send a message BACK to the processor telling it what to do.
And we can arrange it so when the job is finished the communication
channels evaporate and then the useless continuations will evaporate
automatically.
We no longer have an issue with liveness of stack frames (provided
we organise the ownership of channels properly).
The real beauty of this solution is that you don't pass a closure as a
continuation,
you're passing instead a control path. Its the same thing, logically, but it's
governed by protocol. The error handler is a COROUTINE.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience. Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
