Today I have decided to play with control flow.
I have re-enabled the control flow checks.
What these do is try to prevent unexpected control flow outcomes:
* drop off the end of a function without returning a value
* unexpected infinite loop
* unexpected non-returning
and also:
* unreachable code removed
Although this seems simple it isn't quite so straight forward.
* code can be "non-return", for example an assertion or
other code throwing an exception
* code can deliberately infinite loop, which is very
common in monitoring or processing code for threads
* returns can be hard to detect if they're all done in
match branches where exhaustion is hard to determine.
Felix currently has no way to determine exhaustion
except in some trivial cases (and not sure about these):
* simple if/then/else
* wildcard for last branch
Note that a match like:
match x,y with
| _, ?a => ...
must terminate: there's only one branch and it catches everything,
but the condition is non-trivial.
At present this doesn't compile:
gen f(a:bool) = {
if a do
yield 1;
else
return 2;
done
//return 99;
}
without uncommenting the useless return 99.
Felix actually allows you to label C code as non-return.
Not sure about Felix code though! Felix code can non-return
at least by assertions or by a non-local goto.
So what we want is a proper algorithm here than handles all the
cases right. We want to enforce *declaring* the properties of code:
it it is meant to infinite loop, you have to say so (because that's
unusual!).
=============
As well as getting this detectors right and implementing stricter enforcement,
I want to examine some new control options.
Felix currently supports non-local goto:
proc a() {
proc b() { goto endoff; }
b();
println$ "hi";
endoff:>
}
You may wonder what this is for. It has two uses:
1. It allows you to write code containing gotos, where Felix wraps the
code into a procedure "behind the scenes":
proc a () {
match x with
| true => some-code; goto finish;
| false => ...
endmatch;
finish:>
}
Looks ok, but secretly the match branch code is wrapped into a procedure.
In fact, this procedure will probably be inlined away, but maybe not.
It should still work, and certainly the error checking should pass.
The point is here the user is jumping out of a procedure they can't see.
The second use is for error handling:
proc f() {
proc error () { goto catch; }
g (error);
return;
catch:> println "Error";
}
This is ugly code. But the idea here is you pass the error handler to g,
which can call it if there's an error, and you "catch" the exception
at label "catch". Felix unwinds the stack for you. It's like throwing an
exception, except you cannot do the "throw" unless there's a
"catch". [Note: Felix doesn't ensure the catch is upstream, which it
should. The error() handler could be called after the f() procedure
is gone .. bad bad..]
The syntax is ugly here: return; catch:> is assembler code!
How horrible, having to stop a drop thru into the error handler!
You can actually do a non-local goto from inside a function.
It's done by the amazing technique of *throwing* the continuation
to want to continue on with (I mean, you throw a con_t object
in C++ and the procedure run driver code catches it and
starts running it).
Felix can do some interesting things with continuations.
Generators with yields are just the tip of the iceberg.
time to explore some more!
One idea:
return (value) from name;
This is a non-local return. It returns not from the current
function, but the named one. Good to get out of deep
recursions both in case or error, or just in case we already
found the final result.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
