On 20/08/2012, at 3:07 PM, Dobes Vandermeer wrote:
> When you say that "all hell breaks loose" if the target frame is not active,
> what do you mean? Some kind of runtime error?
On my sample, an infinite loop happened.
I'm not sure how to stop this. It can probably be done.
Normally its safe to send closures out of the function that
made them, provided they only refer to data in their scope.
If you refer to a jump label however, you need the stack
frame to be active (i.e. not returned yet) so the return
can fall down the subroutine stack in the usual way.
>
> I thought the work with monads and option types was there to avoid this kind
> of problem.
This feature can be used safely is it is wrapped in a library
function which has been checked to be safe. For example
you could call a binary chop style search which uses an early
exit to get out of the chop when the target is found.
Provided that code was OK, you can safely call the search routine.
It may be possible to do better with analysis or using the type system,
>
> Maybe I've been overly brainwashed by the "goto haters" out there but I don't
> think returning an opt[] or other union type is all that bad.
You're missing the context. Consider this:
fold_left (fun (acc:bool) (elt:bool) => acc and elt) somelistofbool;
This calculates the "and" of all the bools in the list. On average it is twice
as slow as it needs to be because it doesn't exit as soon as the accumulator
becomes false. Once you're inside the fold, you cannot stop it.
> Or for a proc putting it into a shared var somewhere. How is this done in
> OCaml and Haskell? Or is that a terribly broken experience in those
> languages?
It's broken in Ocaml. In Ocaml, you would use an exception for an early exit.
This works fine if you remember to catch it :) However exception handlers
in Ocaml defeat tail recursion optimisation (if they're in the wrong place)
since a tail call wrapped in a try block is not actually in tail position.
>
> Let's say you want to write some procedure like for_lines_in_file(...) that
> calls a procedure for each line in a file, then closes the file. If someone
> does one of these non-local gotos out of that loop, will you still close the
> file? I'm guessing not.
Not if they jump past the close.
> This non-local goto looks like the devil to me.
It is.
you need to first understand that Felix low level language has (conditional)
goto because
it is the basis on which all control structures are built. Loops, tail
recursion, all of these
things require goto. That's the underlying machine instruction. Its a superior
pain
C doesn't have computed gotos (if you're running gcc it does have and Felix
uses it, its much faster than switch).
Non-local gotos sound evil, but we have to have them, to allow wrapping
code in blocks (functions or procedures) temporarily, then inlining them.
That makes the previously non-local goto local again, but this happens
after type checking.
> The further down this road of non-local gotos (and gotos in general) you go,
> the more you are going to turn people off the language, not to mention adding
> to the list of dangerous and confusing language misfeatures you've got that
> already will turn people off the language when they learn of them.
You do not have to use them. We don't even have to document them.
Goto isn't a misfeature. Its essential. You cannot define a for loop, while
loop,
or anything else without a conditional goto.
It's not necessary that the goto be in the concrete syntax.
We could leave it out. Then you would have to use Scheme action codes
of the parser to define loops. You would not be able to do it in the library.
Down the track a switch that said: "Allow dangerous features" could
be added to flx, and the default would be to disallow them, including
gotos -- in your program. The standard library would be compiled by this
time so use there wouldn't be affected.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
