1. Warnings in Euphoria 2.5
- Posted by "Juergen Luethje" <j.lue at gmx.de> Jan 30, 2005
- 452 views
Hi all, Euphoria 2.5 has the new feature, that the interpreter parses the whole program before it starts executing it. This brings the big advantage, that syntax errors will be found more reliably than in Eu 2.4 and earlier. What about the warnings? The following program indicates, that they are still issued at run-time and not at parse-time:
------------------------[ show.exw ]------------------------ -- run with Eu 2.5 beta include misc.e procedure help() puts(1, "Usage: exw show.exw <command-line arguments>" & "\n\nPress Enter ...\n") if getc(0) then end if abort(2) end procedure constant CMD = command_line() integer x if length(CMD) < 3 then help() end if puts(1, "Command-line arguments are:\n") pretty_print(1, CMD[3..$], {3}) puts(1, "\n\nPress Enter ...\n") if getc(0) then end if ------------------------------------------------------------
When I call 'exw show.exw foo bar', then the command-line arguments are displayed, and after pressing [Enter], the program says Warning: local variable x in show.exw is not used as expected. But when I just call 'exw show.exw', then the message in procedure help() is displayed, and the program does not show any warning. So it can depend on the program flow and the input data, whether or not a warning is shown. Is it possible/desirable to change the behaviour of the interpreter, so that causes of warnings are detected at parse-time? Regards, Juergen -- Have you read a good program lately?
2. Re: Warnings in Euphoria 2.5
- Posted by D. Newhall <derek_newhall at yahoo.com> Jan 30, 2005
- 450 views
- Last edited Jan 31, 2005
> So it can depend on the program flow and the input data, whether or not > a warning is shown. Is it possible/desirable to change the behaviour of > the interpreter, so that causes of warnings are detected at parse-time? The behavior of the interpreter is to print out all the warnings at the end of program execution so wether or not warnings are discovered during parsing or execution makes no difference since the output is the same. It makes more sence to print it at the end in my opinion because if you give a program away having it start up with "Warning: variable foo in bar.ex is not used" doesn't make the program look good.
3. Re: Warnings in Euphoria 2.5
- Posted by "Juergen Luethje" <j.lue at gmx.de> Jan 30, 2005
- 452 views
- Last edited Jan 31, 2005
D. Newhall wrote: >> So it can depend on the program flow and the input data, whether or not >> a warning is shown. Is it possible/desirable to change the behaviour of >> the interpreter, so that causes of warnings are detected at parse-time? > > The behavior of the interpreter is to print out all the warnings at the > end of program execution so wether or not warnings are discovered > during parsing or execution makes no difference since the output is the > same. > It makes more sence to print it at the end in my opinion because if you > give a program away having it start up with "Warning: variable foo in > bar.ex is not used" doesn't make the program look good. The warnings are for the developer of the program, not for the end-user. So I will not give away a program that issues warnings at all. However, that's not the point here. I did not write that I want the interpeter to print warnings at the start of a program. I wrote something completely different. Regards, Juergen
4. Re: Warnings in Euphoria 2.5
- Posted by Robert Craig <rds at RapidEuphoria.com> Jan 31, 2005
- 440 views
Juergen Luethje wrote: > Euphoria 2.5 has the new feature, that the interpreter parses the whole > program before it starts executing it. > This brings the big advantage, that syntax errors will be found more > reliably than in Eu 2.4 and earlier. > > What about the warnings? The following program indicates, that they are > still issued at run-time and not at parse-time: <snip> > So it can depend on the program flow and the input data, whether or not > a warning is shown. Is it possible/desirable to change the behaviour of > the interpreter, so that causes of warnings are detected at parse-time? Warnings are always "detected" at parse time. A long time ago (way before 2.4), warnings were displayed immediately, as the problems were found. However, many programs would clear the screen, or print a bunch of stuff that would make it impossible to see the warnings. So things were changed so that warnings were saved up, and issued as soon as the program terminated. That way they were hard to miss. In 2.5, if you call abort() to terminate your program, the warnings will not be printed. You'll only see them at a "normal" termination, i.e. falling off the end of the main file. I'll fix this so they are printed out, even if you call abort(). Thanks, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
5. Re: Warnings in Euphoria 2.5
- Posted by "Juergen Luethje" <j.lue at gmx.de> Jan 31, 2005
- 446 views
Robert Craig wrote: [big snip] > In 2.5, if you call > abort() to terminate your program, the warnings will not be printed. > You'll only see them at a "normal" termination, i.e. falling off the end > of the main file. I'll fix this so they are printed out, even > if you call abort(). Thanks for the comprehensive explanation. I like the warnings, they are a great tool that helps to keep the source code clean. Regards, Juergen
6. Re: Warnings in Euphoria 2.5
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Jan 31, 2005
- 456 views
On Sun, 30 Jan 2005 21:10:53 -0800, Robert Craig <guest at RapidEuphoria.com> wrote: >In 2.5, if you call >abort() to terminate your program, the warnings will not be printed. >You'll only see them at a "normal" termination, i.e. falling off the end >of the main file. I'll fix this so they are printed out, even >if you call abort(). I'd like to have some way to terminate execution if there are any warnings, perhaps abort({0}), ie abort changed to accept an object, if it is a sequence then check for warnings and if any show them before terminating with param[1]. If there are no warnings it should carry on as usual. I would normally place such a statement immediately before the WinMain() call. Regards, Pete