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"
<hansl>
loop i=1..4
if $i < 3
print "Gretl is awesome."
elif $i == 3
print "Let's quit now."
quit
endif
endloop
</hansl>
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)"
<hansl>
FOO = 1
if FOO == 1
print "gretl is awesome"
quit
endif
</hansl>
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.
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.)
Allin