1. Warnings in Euphoria 2.5

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?

new topic     » topic index » view message » categorize

2. Re: Warnings in Euphoria 2.5

> 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.

new topic     » goto parent     » topic index » view message » categorize

3. Re: Warnings in Euphoria 2.5

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

new topic     » goto parent     » topic index » view message » categorize

4. Re: Warnings in Euphoria 2.5

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

new topic     » goto parent     » topic index » view message » categorize

5. Re: Warnings in Euphoria 2.5

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

new topic     » goto parent     » topic index » view message » categorize

6. Re: Warnings in Euphoria 2.5

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

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu