3:49 a.m.
Hi,
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>
Thanks,
Artur
6:22 a.m.
Am 27.02.2021 um 09:49 schrieb Artur Tarassow:
Hi,
Just by chance I've found this (weird?) behavior of the quit keyword
when using the GUI:
I think the 'quit' command is a little under-documented in the sense
that I believe it is not meant for the GUI or for real programming.
Instead it's primarily for CLI use, probably as an alternative to the
batch (-b) option when running gretlcli on the shell.
Also when I execute 'quit' in the GUI console, the program gretl itself
is not shut down, so in contrast to the doc it's not the equivalent of
doing File/Exit. (Instead only the console is closed.)
cheers
sven
9:02 a.m.
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
11:32 a.m.
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"
>
> <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.
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.
Good idea.
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.)
Definitely not.
Thanks,
Artur
1359
days inactive
1359
days old
4 comments
3 participants
participants (3)
-
Allin Cottrell -
Artur Tarassow -
Sven Schreiber