Am 27.02.21 um 15:02 schrieb Allin Cottrell:
On Sat, 27 Feb 2021, Artur Tarassow wrote:
> Just by chance I've found this (weird?) behavior of the quit keyword
> when using the GUI:
> 1) The following script fails to run.
> 2) I get the somehow misleading message:
> "Unbalanced "loop"/"endloop" in script"
> loop i=1..4
> if $i < 3
> print "Gretl is awesome."
> elif $i == 3
> print "Let's quit now."
> Another issue: The following script:
> 1) Prints the message
> 2) stdout prints "Script done"
> 3) The GUI shows prints the error:
> "Unmatched "if" in script (fixed)"
> FOO = 1
> if FOO == 1
> print "gretl is awesome"
True, "quit" had a few issues. The "unmatched if" message is
understandable (since we never get to "endif") but clearly unwanted.
That's now fixed.
Thank you, Allin!
Other than that, quit had a "hair-trigger" quality: if you
used it in a
loop or a function its effect was to abort compilation as soon as it was
encountered. This sort-of made sense if you were defining a function or
loop via the GUI console, or in interactive use of gretlcli, but that's
a pretty uncommon use-mode.
Yesterday I put in place what I regard as a fix for functions: you can't
use "quit" in a function. And today I'm doing the same for loops: no use
of "quit" there either.
It surely makes sense that you can't quit inside a function: your
options for getting out are (a) returning something or (b) breaking with
an error flagged (funcerr or errorif). And with a loop (in a main
script), if you want to quit you should use "break" first, so the loop
can be torn down coherently.
(In C you can use exit() anywhere, and that can have surprising results,
for example if some third-party library you're linked against decides to
call exit() on an error condition: "Why the heck did my program stop?!"
We don't want that kind of uncontrolled exit in hansl.)