Re: buggy 4.0 program
- Posted by kinz Dec 11, 2008
- 1661 views
Matt & Igor: How about: Missing reference: Variable 'a'
Bernie, the problem seems to be more serious than just new wording of the error message. See please the screenshot of the next even more simple programm b.e:
and outputs of 1.0 - 3.1.1:
and 4.0:
Igor, please let me explain why the v3 message is different to the v4 message.
In v3, when a reference to an identifier was found, it checked that the identifier had already been declared. If it hasn't it issued the message saying that 'a' had not been declared.
Ok, "declare then use", old good familiar safe simple reliable scheme.
v4 has a different approach. In v4, an identifier not is discovered missing until all the program has been parsed.
Ok, why not? But my buggy b.e program is complete, all, so to say.
There is nothing to parse any more, I do not include libs. My program
is complete but just buggy. And similar buggy 'a' we may meet in some big program too,
as typo etc etc.
Instead, it assumes that a reference to an unknown identifier is valid
and continues with the parsing effort.
Why does it "think", so to say, that I'm going to use or already using the forward
referencing? I do not need the forward referencing at all, for now, maybe.
In this case, it finds two adjacent identifiers at the begining of a statement,
namely "a" and "puts". However, the only things that can come legally
after an identifier at the begining of a statement is one of the assignment operations, a left-parethensis,
or a left-square bracket. Certainly one cannot have two adjacent identifiers.
So in that context, the v4 message "Syntax error - expecting to see ..." is sensible.
Well, all said is clear enough, thanks.
Let's now just follow the recommendations of the interpreter messages.
Remember please, it wanted to see some '=' in b.e,
let's give it expected one:
--c.e a= puts(1,"test") --
It wanted to see 'expression' in c.e,
let's give it expression:
--d.e a=1 puts(1,"test") --
It found some errors in d.e, let's give it one bug more:
--e.e a=1- puts(1,"test") --
It wanted to see 'expression' in e.e, but do not see the error,
let's give it one bug more:
--f.e a=1-& puts(1,"test") --
Good, pointer shows '&' exactly.
But it wanted expression here. Let's give it
expression:
--g.e a=1-sin(a) puts(1,"test") --
It sees two unresolved references now.
But bug sits on different place.
So, it allows you to write buggy program and hopes
to see resolved references some future time.
Is it good? I do not think it is good.
Let's see yet another buggy program:
--h.e a=1-sin(a)+cos(a)*tan(a)/log(b)+power(a,b)-10 puts(1,"test") --
It sees a bunch of unresolved references, but just two
bugs sit on a different place.
So, there may be two different situations in a program:
presence of non-declared symbol(s) and conflict of declared symbols.
Non-declared symbols have to be just declared.
Error message - something like to "Can not find declaration of: [list]"
Or "Declare please: [list]", or just old good message of 1.0.
But conflict of declared symbols have to be resolved.
Error massage - "Unresolved conflict of: [list]" or something similar.
Also, in v4, if there are syntax errors, it doesn't go on to tell you about possible
'missing' identifiers - because it maybe that certain syntax errors cause identifiers to go missing, e.g.
---- integer a() a = 1 ----
It is not much use reporting that the declaration is invalid and reporting that the 'a' is missing.
I do not have some certain opinion on this one for now.
In your previous message, the one that Bernie replied to, I wasn't sure if you were complaining about the content of the message or that is used the plural form when only one variable was missing. There is not much to be gained by using singular forms in this message context so I can't see that we will be attempting to do so.
There are some neutral forms well suitable for both plural and singular cases
in Russian and in English as well, I'm sure.
My trouble was and is about content mainly.
Note how I used some creole tags in this reply to make it easier to write and read.
Thank you very much for very useful examples.
Regards,
Igor Kachan
kinz@peterlink.ru
