1. Rob, no reply? Minor bug found in 3.1 and previous
- Posted by Al Getz <Xaxo at aol?com>
Jul 06, 2007
-
Last edited Jul 07, 2007
Al Getz wrote:
>
> Robert Craig wrote:
> >
> > Al Getz wrote:
> > >
> > > --program:
> > > constant x=1
> > > x=2
> > > --end program
> > >
> > > --error message:
> > > C:\Euphoria\Projects\Test\test.exw:2
> > > x has not been declared
> > > x=2
> > > ^
> > >
> > > Press Enter
> > > --end message
> > >
> > >
> > > Error message should be "May not change the value of a constant",
> > > or something like that.
> >
> > Yes, that would be a better message.
> > You've caught the parser and scanner at an awkward moment.
> > What's happening here is that you're making the scanner
> > look up x in the symbol table, when the parser hasn't quite
> > finished the constant declaration of x. The fact that
> > you enter a new-line character after constant x = 1
> > is no more significant than typing a blank, and
> > the parser needs to see the next scanner token to be sure that
> > the constant declaration is really finished. You might have
> > had:
> > }}}
<eucode>
> > constant x = 1
> > + 1 -- x is 2
> > </eucode>
{{{
> > for instance. Until the parser digests the next token after " = 1",
> > it can't be sure that the declaration is finished,
> > and can't record that x is a constant with value 1
> > in the symbol table.
> >
> > Regards,
> > Rob Craig
> > Rapid Deployment Software
> > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
>
>
> Hi Rob,
>
>
> Ok, but it looks to me like logically it is not too hard to detect
> the end of a constant declaration. Whether or not the parser can
> do this yet or not i dont know, apparently it can not.
>
> I think i see what you are talking about however, in that the
> following program gives the same error:
>
> --
> constant y=2
> constant x=y x=1
> --
>
> Apparently though something sees the whitespace and is able to terminate the
> "x=y" part once the 'x' is encountered, it is just not able to understand
> the difference
> between a comma or whitespace or other, non-variable-starter characters
> (which would tell it to keep parsing the constant declaration) and
> an actual variable-starter character.
> In other words, if it encounters a character that is in the set of
> all characters that can be a variable starter then it is forced to
> terminate the constant declaration. Isnt the current set A to Z and
> a to z ? Note there is no possibilty of:
>
> constant x=y x --(which would trigger an "x is not declared" error)
>
> where the user intended
>
> constant x=yx
>
>
> and also
>
> constant x=x
>
> would probably trigger an "x is not declared" error (referring to
> the second x).
>
>
> Make sense or did i assume too much?
>
>
> Bottom line is that the main reason i mentioned this is because
> when you get the error message "x is not declared" it makes you
> think you can go somewhere near the beginning of the program and
> type "atom x" and all will be fine 
> Only after typing that will the real problem show itself (x was
> already declared as a constant) on the next run.
>
>
> Al
>
> E boa sorte com sua programacao Euphoria!
>
>
> My bumper sticker: "I brake for LED's"
>
Take care,
Al
E boa sorte com sua programacao Euphoria!
My bumper sticker: "I brake for LED's"
From "Black Knight":
"I can live with losing the good fight,
but i can not live without fighting it".
"Well on second thought, maybe not."
2. Re: Rob, no reply? Minor bug found in 3.1 and previous
Al Getz wrote:
>
> Al Getz wrote:
> >
> > > constant x=1 x
> > > --error message:
> > > x has not been declared
> >
> > Robert Craig wrote:
> > > You've caught the parser and scanner at an awkward moment.
In procedure Global_declaration(symtab_index type_ptr, integer is_global):
-- temporarily hide sym so it can't be used in defining itself
buckets[SymTab[sym][S_HASHVAL]] = SymTab[sym][S_SAMEHASH]
tok_match(EQUALS)
StartSourceLine(FALSE)
emit_opnd(sym)
Expr() -- no new symbols can be defined in here
buckets[SymTab[sym][S_HASHVAL]] = sym
Now, and there will be a shed-load of knock-on effects if you do this,
comment out the first (and last) lines, gets a more respectable "cannot change
the value of a constant". What seems to be happening here is that the "temporary
hide" causes a new SC_UNDEFINED entry to be added to symtab, which is putback()
and retrieved via next_token().
Probably difficult to better without imposing significant (and unwarranted, imo)
overhead. The most obvious and most costly fix is to remove the above "unlink"
and insert dozens or more additional checks for such cases throughout the parser.
A possibly better fix might be to detect when the last added symtab entry would
have been the unlinked one, so remove it and reset the "putback()" token.
Good Luck 
Regards,
Pete
3. Re: Rob, no reply? Minor bug found in 3.1 and previous
I don't plan to do anything about this.
It's a rare situation, and I don't think it's
worth the trouble to try to improve the error message.
Al Getz wrote:
>
> Al Getz wrote:
> >
> > Robert Craig wrote:
> > >
> > > Al Getz wrote:
> > > >
> > > > --program:
> > > > constant x=1
> > > > x=2
> > > > --end program
> > > >
> > > > --error message:
> > > > C:\Euphoria\Projects\Test\test.exw:2
> > > > x has not been declared
> > > > x=2
> > > > ^
> > > >
> > > > Press Enter
> > > > --end message
> > > >
> > > >
> > > > Error message should be "May not change the value of a constant",
> > > > or something like that.
> > >
> > > Yes, that would be a better message.
> > > You've caught the parser and scanner at an awkward moment.
> > > What's happening here is that you're making the scanner
> > > look up x in the symbol table, when the parser hasn't quite
> > > finished the constant declaration of x. The fact that
> > > you enter a new-line character after constant x = 1
> > > is no more significant than typing a blank, and
> > > the parser needs to see the next scanner token to be sure that
> > > the constant declaration is really finished. You might have
> > > had:
> > > }}}
<eucode>
> > > constant x = 1
> > > + 1 -- x is 2
> > > </eucode>
{{{
> > > for instance. Until the parser digests the next token after " = 1",
> > > it can't be sure that the declaration is finished,
> > > and can't record that x is a constant with value 1
> > > in the symbol table.
> > >
> > > Regards,
> > > Rob Craig
> > > Rapid Deployment Software
> > > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
> >
> >
> > Hi Rob,
> >
> >
> > Ok, but it looks to me like logically it is not too hard to detect
> > the end of a constant declaration. Whether or not the parser can
> > do this yet or not i dont know, apparently it can not.
> >
> > I think i see what you are talking about however, in that the
> > following program gives the same error:
> >
> > --
> > constant y=2
> > constant x=y x=1
> > --
> >
> > Apparently though something sees the whitespace and is able to terminate the
> > "x=y" part once the 'x' is encountered, it is just not able to understand
> > the difference
> > between a comma or whitespace or other, non-variable-starter characters
> > (which would tell it to keep parsing the constant declaration) and
> > an actual variable-starter character.
> > In other words, if it encounters a character that is in the set of
> > all characters that can be a variable starter then it is forced to
> > terminate the constant declaration. Isnt the current set A to Z and
> > a to z ? Note there is no possibilty of:
> >
> > constant x=y x --(which would trigger an "x is not declared" error)
> >
> > where the user intended
> >
> > constant x=yx
> >
> >
> > and also
> >
> > constant x=x
> >
> > would probably trigger an "x is not declared" error (referring to
> > the second x).
> >
> >
> > Make sense or did i assume too much?
> >
> >
> > Bottom line is that the main reason i mentioned this is because
> > when you get the error message "x is not declared" it makes you
> > think you can go somewhere near the beginning of the program and
> > type "atom x" and all will be fine
> > Only after typing that will the real problem show itself (x was
> > already declared as a constant) on the next run.
> >
> >
> > Al
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
4. Re: Rob, no reply? Minor bug found in 3.1 and previous
Robert Craig wrote:
>
> I don't plan to do anything about this.
> It's a rare situation, and I don't think it's
> worth the trouble to try to improve the error message.
>
> Al Getz wrote:
> >
> > Al Getz wrote:
> > >
> > > Robert Craig wrote:
> > > >
> > > > Al Getz wrote:
> > > > >
> > > > > --program:
> > > > > constant x=1
> > > > > x=2
> > > > > --end program
> > > > >
> > > > > --error message:
> > > > > C:\Euphoria\Projects\Test\test.exw:2
> > > > > x has not been declared
> > > > > x=2
> > > > > ^
> > > > >
> > > > > Press Enter
> > > > > --end message
> > > > >
> > > > >
> > > > > Error message should be "May not change the value of a constant",
> > > > > or something like that.
> > > >
> > > > Yes, that would be a better message.
> > > > You've caught the parser and scanner at an awkward moment.
> > > > What's happening here is that you're making the scanner
> > > > look up x in the symbol table, when the parser hasn't quite
> > > > finished the constant declaration of x. The fact that
> > > > you enter a new-line character after constant x = 1
> > > > is no more significant than typing a blank, and
> > > > the parser needs to see the next scanner token to be sure that
> > > > the constant declaration is really finished. You might have
> > > > had:
> > > > }}}
<eucode>
> > > > constant x = 1
> > > > + 1 -- x is 2
> > > > </eucode>
{{{
> > > > for instance. Until the parser digests the next token after " = 1",
> > > > it can't be sure that the declaration is finished,
> > > > and can't record that x is a constant with value 1
> > > > in the symbol table.
> > > >
> > > > Regards,
> > > > Rob Craig
> > > > Rapid Deployment Software
> > > > <a
> > > > href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
> > >
> > >
> > > Hi Rob,
> > >
> > >
> > > Ok, but it looks to me like logically it is not too hard to detect
> > > the end of a constant declaration. Whether or not the parser can
> > > do this yet or not i dont know, apparently it can not.
> > >
> > > I think i see what you are talking about however, in that the
> > > following program gives the same error:
> > >
> > > --
> > > constant y=2
> > > constant x=y x=1
> > > --
> > >
> > > Apparently though something sees the whitespace and is able to terminate
> > > the
> > > "x=y" part once the 'x' is encountered, it is just not able to understand
> > > the difference
> > > between a comma or whitespace or other, non-variable-starter characters
> > > (which would tell it to keep parsing the constant declaration) and
> > > an actual variable-starter character.
> > > In other words, if it encounters a character that is in the set of
> > > all characters that can be a variable starter then it is forced to
> > > terminate the constant declaration. Isnt the current set A to Z and
> > > a to z ? Note there is no possibilty of:
> > >
> > > constant x=y x --(which would trigger an "x is not declared" error)
> > >
> > > where the user intended
> > >
> > > constant x=yx
> > >
> > >
> > > and also
> > >
> > > constant x=x
> > >
> > > would probably trigger an "x is not declared" error (referring to
> > > the second x).
> > >
> > >
> > > Make sense or did i assume too much?
> > >
> > >
> > > Bottom line is that the main reason i mentioned this is because
> > > when you get the error message "x is not declared" it makes you
> > > think you can go somewhere near the beginning of the program and
> > > type "atom x" and all will be fine
> > > Only after typing that will the real problem show itself (x was
> > > already declared as a constant) on the next run.
> > >
> > >
> > > Al
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
Hi again,
Yeah, im not going to loose any sleep over this either, but i thought
for completeness it was worth mentioning. Someday, somebody, somewhere,
may wish to see a Euphoria with zero bugs (or at least all the known ones
eliminated).
Take care,
Al
E boa sorte com sua programacao Euphoria!
My bumper sticker: "I brake for LED's"
From "Black Knight":
"I can live with losing the good fight,
but i can not live without fighting it".
"Well on second thought, maybe not."
5. Re: Rob, no reply? Minor bug found in 3.1 and previous
Al Getz wrote:
>
> Robert Craig wrote:
> >
> > I don't plan to do anything about this.
> > It's a rare situation, and I don't think it's
> > worth the trouble to try to improve the error message.
> >
> > Al Getz wrote:
> > >
> > > Al Getz wrote:
> > > >
> > > > Robert Craig wrote:
> > > > >
> > > > > Al Getz wrote:
> > > > > >
> > > > > > --program:
> > > > > > constant x=1
> > > > > > x=2
> > > > > > --end program
> > > > > >
> > > > > > --error message:
> > > > > > C:\Euphoria\Projects\Test\test.exw:2
> > > > > > x has not been declared
> > > > > > x=2
> > > > > > ^
> > > > > >
> > > > > > Press Enter
> > > > > > --end message
> > > > > >
> > > > > >
> > > > > > Error message should be "May not change the value of a constant",
> > > > > > or something like that.
> > > > >
> > > > > Yes, that would be a better message.
> > > > > You've caught the parser and scanner at an awkward moment.
> > > > > What's happening here is that you're making the scanner
> > > > > look up x in the symbol table, when the parser hasn't quite
> > > > > finished the constant declaration of x. The fact that
> > > > > you enter a new-line character after constant x = 1
> > > > > is no more significant than typing a blank, and
> > > > > the parser needs to see the next scanner token to be sure that
> > > > > the constant declaration is really finished. You might have
> > > > > had:
> > > > > }}}
<eucode>
> > > > > constant x = 1
> > > > > + 1 -- x is 2
> > > > > </eucode>
{{{
> > > > > for instance. Until the parser digests the next token after " = 1",
> > > > > it can't be sure that the declaration is finished,
> > > > > and can't record that x is a constant with value 1
> > > > > in the symbol table.
> > > > >
> > > > > Regards,
> > > > > Rob Craig
> > > > > Rapid Deployment Software
> > > > > <a
> > > > > href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
> > > >
> > > >
> > > > Hi Rob,
> > > >
> > > >
> > > > Ok, but it looks to me like logically it is not too hard to detect
> > > > the end of a constant declaration. Whether or not the parser can
> > > > do this yet or not i dont know, apparently it can not.
> > > >
> > > > I think i see what you are talking about however, in that the
> > > > following program gives the same error:
> > > >
> > > > --
> > > > constant y=2
> > > > constant x=y x=1
> > > > --
> > > >
> > > > Apparently though something sees the whitespace and is able to terminate
> > > > the
> > > > "x=y" part once the 'x' is encountered, it is just not able to
> > > > understand
> > > > the difference
> > > > between a comma or whitespace or other, non-variable-starter characters
> > > > (which would tell it to keep parsing the constant declaration) and
> > > > an actual variable-starter character.
> > > > In other words, if it encounters a character that is in the set of
> > > > all characters that can be a variable starter then it is forced to
> > > > terminate the constant declaration. Isnt the current set A to Z and
> > > > a to z ? Note there is no possibilty of:
> > > >
> > > > constant x=y x --(which would trigger an "x is not declared" error)
> > > >
> > > > where the user intended
> > > >
> > > > constant x=yx
> > > >
> > > >
> > > > and also
> > > >
> > > > constant x=x
> > > >
> > > > would probably trigger an "x is not declared" error (referring to
> > > > the second x).
> > > >
> > > >
> > > > Make sense or did i assume too much?
> > > >
> > > >
> > > > Bottom line is that the main reason i mentioned this is because
> > > > when you get the error message "x is not declared" it makes you
> > > > think you can go somewhere near the beginning of the program and
> > > > type "atom x" and all will be fine
> > > > Only after typing that will the real problem show itself (x was
> > > > already declared as a constant) on the next run.
> > > >
> > > >
> > > > Al
> >
> > Regards,
> > Rob Craig
> > Rapid Deployment Software
> > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
>
>
> Hi again,
>
>
> Yeah, im not going to loose any sleep over this either, but i thought
> for completeness it was worth mentioning. Someday, somebody, somewhere,
> may wish to see a Euphoria with zero bugs (or at least all the known ones
> eliminated).
>
>
> Al
>
> E boa sorte com sua programacao Euphoria!
>
>
> My bumper sticker: "I brake for LED's"
>
I can't count the number of times Eu gives me an error which is not the one I
committed.
This is not specific to Euphoria. The error meaasges are laid in the logic of
the parser or scanner, which are completely alien to the coder's.
These are not bugs, since they re not behaviours different from documented ones.
Second guessing the coder would be a somewhat huge investlment, probably more
adequate in an IDE - there is currently none for Euphoria proper - than inside
the Euphoria interpreter. It would certainly be useful though.
When I said there is none, this not exactly true. Visual Euphoria v1.02 by
"average Joe" is a starting point. Not an full fledged IDE for sure, but adding
to it could make it into it. I have already enhanced it a lot, have to retrieve
the right set of includes to make it work again.
CChris
6. Re: Rob, no reply? Minor bug found in 3.1 and previous
CChris wrote:
> I can't count the number of times Eu gives me an error which is not the one
> I committed.
I would be interested to see a list of these logged, eg on EuWiki.
> This is not specific to Euphoria.
Correct. All programming languages have their share of duff messages.
While I am happy (as in this case) to accept a fix is not worthwhile, maybe now
and then a fresh set of eyes might spot a zero-cost fix, you never know.
(I felt fairly close on this one, not that I would have put in the testing)
Hints against such a list might also help those not yet accustomed to these
misleading messages (experience probably now numbs me to such).
Obviously the testing needed for any such minor gains remains an issue.
Regards,
Pete
