OpenEuphoria

1. buggy 4.0 program

• Posted by kinz Dec 05, 2008
• 1739 views

Dear EU users,

Let's try the simplest buggy program:

http://pl-euphoria.narod.ru/program.png

and output screen of ex.exe running this program:

http://pl-euphoria.narod.ru/bug.png

My mistakes are:

- a is not declared

- a doesn't have a value

So, it seems to me that ex.exe doesn't catch the mistakes properly and doesn't point to real place of mistake - it points to good puts() now.

Or, maybe, this is some new behaviour of ex.exe?

Regards, Igor Kachan kinz@peterlink.ru

3. Re: buggy 4.0 program

• Posted by euphoric (admin) Dec 05, 2008
• 1698 views

That's happening to me a lot. Hopefully someday I'll find time to file a report.

5. Re: buggy 4.0 program

• Posted by mattlewis (admin) Dec 05, 2008
• 1728 views

You file reports all the time. Give someone else a chance, fer cryin out loud.

This is now fixed in r1245, BTW.

Matt

7. Re: buggy 4.0 program

• Posted by DerekParnell (admin) Dec 05, 2008
• 1718 views

Not quite fixed yet though ...

---- 
? a 
printf(1, "%d test\n", a) 
integer a = 1 
---- 

c:\temp>exwc test.ex 
test.ex:2 
Errors resolving the following references: 
        test.ex (2): a 
        test.ex (2): a 
 
printf(1, "%d test\n", a) 
                        ^ 
 
 
Press Enter 

9. Re: buggy 4.0 program

• Posted by donCole01 Dec 05, 2008
• 1671 views
• Last edited Dec 06, 2008

11. Re: buggy 4.0 program

• Posted by jeremy (admin) Dec 06, 2008
• 1702 views

I think we should probably move to weekly releases of alpha's. If, every time a bug is fix, a new release is made, the devs would not get anything done but releasing updates. A weekly update may be feasable. Typically, the way a software project works is an alpha is released, many people use it, report 100 bugs, and a very good percentage of those bugs are fixed, then the 2nd alpha is released.

Jeremy

13. Re: buggy 4.0 program

• Posted by kinz Dec 10, 2008
• 1687 views

Ok, I have all new binaries now and can
compile the recent ones on my machine as well.

Let's see that simplest buggy program again:

http://pl-euphoria.narod.ru/program.png

and the interpreters' output, version 1.0:

http://pl-euphoria.narod.ru/1.0.png

bilingual version 2.5, English mode:

http://pl-euphoria.narod.ru/2.5e.png

bilingual version 2.5, Russian mode:

http://pl-euphoria.narod.ru/2.5r.png

the last version of 3 series, 3.1.1:

http://pl-euphoria.narod.ru/3.1.1.png

and almost the recent revision of 4.0:

http://pl-euphoria.narod.ru/4.0.1249.png

Do you see that there is nothing to do with
4.0 error message about that a.e program?

In that program, there is just single non-declared symbol,
which is a real error.
But 4.0 interpreters still tell us about "resolving" and
point to the empty place just after the real error place.

Regards,
Igor Kachan
kinz@peterlink.ru

15. Re: buggy 4.0 program

• Posted by mattlewis (admin) Dec 10, 2008
• 1699 views

Could you copy the console output into the posts, please? It would make these threads easier to follow. Use the triple curly brackets (I notice that they're not explicitly listed in the help, but you can use the Section: Plain link if you're using Firefox, at leastYMMV with other browsers) like so:

{{{ 
bug.exw:1 
Errors resolving the following references: 
        bug.exw (1): a 
 
? a 
   ^ 

I'll see how I can make it show the beginning of the token instead of the end.

Matt

17. Re: buggy 4.0 program

• Posted by bernie Dec 10, 2008
• 1679 views

Matt, my trouble is not only about pointer position, but, mainly, about real
sense of the issued error message.
There was nothing to resolve in a.e, single reference doesn't require any resolving
at all. But the message just confuses a user - errorS, resolving, referenceS.
There was just non-declared name, single non-declared name in single file.
But pointer ... pointer is almost good ... just x-=1.
So, what about the sense of 4.0 message, sorry?
We have 15 years old tradition of that standard message.

Regards,
Igor Kachan
kinz@peterlink.ru

[/quote] Matt & Igor:
How about:
Missing reference: Variable 'a'

19. Re: buggy 4.0 program

• Posted by DerekParnell (admin) Dec 11, 2008
• 1683 views

kinz said...

bernie said...

 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.

v4 has a different approach. In v4, an identifier not is discovered missing until all the program has been parsed. Instead, it assumes that a reference to an unknown identifier is valid and continues with the parsing effort. 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.

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.

21. Re: buggy 4.0 program

• Posted by m_sabal Dec 11, 2008
• 1639 views

When I look at the error about a missing identifier, I think, "Oh, puts must now be a function." When I see an error about "a is not defined", I think, "Oops, I forgot to put a type in front of a." The power of Euphoria is that the error reported very clearly told me where the problem was, making it very quick to fix. I'm glad some kind of compile-time error is being generated; but I'd rather not go back to the bad old days of C where an error on line 400 could mean a bug in line 25.

23. Re: buggy 4.0 program

• Posted by kinz Dec 11, 2008
• 1662 views

DerekParnell said...

kinz said...

bernie said...

 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.

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.

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.

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.

---- 
integer a() 
a = 1 
---- 

I do not have some certain opinion on this one for now.

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.

Thank you very much for very useful examples.

Regards,
Igor Kachan
kinz@peterlink.ru

25. Re: buggy 4.0 program

• Posted by mattlewis (admin) Dec 11, 2008
• 1622 views

--g.e 
a=1-sin(a) 
puts(1,"test") 
-- 

No, once it can determine that there are bugs in your program, it lets you know. And, by the way, it gives you more information (though we obviously have a little work to do for reporting the correct character in the line).

--h.e 
a=1-sin(a)+cos(a)*tan(a)/log(b)+power(a,b)-10 
puts(1,"test") 
-- 

Yes, in this case, the obvious bug is that you never declared or initialized a and b. The error generation is somewhat naive, in that it doesn't check for duplicates on the same line. It might be better to condense that a bit. But we definitely need to report all of those. Suppose they were typos, and we only reported one. Then you would change the first instance, re-run, and you'd get the same message. I think this would be very frustrating. Obviously, your example is very simple, but consider something like:

sequence foo 
enum SOMETHING, SOMETHING_ELSE 
   ... 
 
? foo[SOMETHIGN][SOMETHING_ELSE][3][SOMETHIGN..$] 

If the error message didn't alert you to the fact that there were two errors for SOMETHIGN, it would be easy to spot the first, but less easy to spot the second. This would be especially true for multi-line expressions, where the reporting is usually on the first line of the expression.

I'm not against changing the text of the errors. It seems clear to me, but it's my native language, and I'm probably too close to the internals, so I can see how it would come across as confusing jargon to someone not used to digging around in the guts of the interpreter.

I don't think there are such constructs in English, unless you put the s in parentheses, or something like that.

   Errors resolving the following reference(s): 

27. Re: buggy 4.0 program

• Posted by DerekParnell (admin) Dec 11, 2008
• 1621 views

The art of error reporting is difficult. Consider ...

---- 
integer a  
. . . lots of code . . . 
a 
puts(1, "test) 
----- 

Now 'a' is not missing. What should the error message be?

And in this case it isn't. The error message is very local to the site of the error.

29. Re: buggy 4.0 program

• Posted by mattlewis (admin) Dec 12, 2008
• 1602 views

You're changing the definition. The parser is single pass. Please, don't argue this point, because you're wrong. The parser reads the code sequentially once. Hence, single pass.

It stops as soon as it finds an error. However, the point at which we can prove an error has changed due to forward referencing. It's a subtle but important distinction. If the only problem was that there were typos or undeclared variables or routines, then yes, we can report on all of the places in the code where that happened. If you have a syntax error, however, we report that immediately, without continuing to look at any more code, just like always.

No, it's still single pass. The effect of the ifdefs is to ignore code within an ifdef that evaluates to false. So if you have ifdef DEBUG# in your code, then if DEBUG isn't defined, the code within that ifdef is treated as though it were commented out.

Matt, there seems to be a contradiction in your words, you say "we cannot know" above, and now, you say "we can report".
[/quote]

Perhaps I was unclear. We cannot know at the point of reading a variable name that it is undeclared in the program. We can only know that when we have read all of the code.

That's fine, although if you use the standard library, you will almost definitely be using code that uses forward referencing.

Matt

31. Re: buggy 4.0 program

• Posted by DerekParnell (admin) Dec 13, 2008
• 1553 views

In map.e; "convert_to_small_map()" and "convert_to_large_map()". These are referenced before they are declared.

33. Re: buggy 4.0 program

• Posted by kinz Dec 13, 2008
• 1725 views

Ok, thanks.
I ran this lib with ex.exe r1261. Nothing happened, good, there is no compile time errors in this lib and in all included libs. Then I renamed convert_to_small_map() and convert_to_large_map() procedures to convert_to_small_map_() and convert_to_large_map_(). So, my new map.e doesn't have any syntax errors, but just two non-declared procedures and two some extra procedures, without syntax errors too.
I ran this changed lib with ex.exe r1261 and got the output screen:

My question, why the error handling system can not separate the non-declared things and other things of the "referencing error" series?

Ok, I've changed the error message in fwdref.e, compiled new ex.exe r1261+ and ran again my test version of map.e with new ex.exe r1261+.
You can see the output screen:

My question, which screen is better?

Regards,
Igor Kachan
kinz@peterlink.ru

35. Re: buggy 4.0 program

• Posted by kinz Dec 13, 2008
• 1601 views

Non-declared exactly:
- the EOF is reached and
- there is no the declaration of the symbol in the whole program.
(The current parser's perspective is zero, so to say. It has nothing to do any more.)

Other things of the "referencing error" series - you do know them better than anyone here.

Regards,
Igor Kachan
kinz@peterlink.ru

37. Re: buggy 4.0 program

• Posted by DerekParnell (admin) Dec 13, 2008
• 1574 views

The current message is better because it does not tell the coder what to do, instead it tells the coder some facts and allows the coder to fix the error in any manner that they see fit.

If the parser finds an unresolved reference it could because of a number reasons:

1. The coder has not attempted to declared the symbol anywhere ^{(which was your assumption)}
2. The coder has declared the symbol but not included it
3. The coder attempted to declared the symbol, but got the spelling wrong
4. The coder has declared the symbol but the reference(s) was mispelled

And I'm sure there are other reasons too.

The point is, rather than insist that the problem be fixed by "Please declare..." messages, we just tell the coder what the current situation actually is. Just the facts.

39. Re: buggy 4.0 program

• Posted by DerekParnell (admin) Dec 15, 2008
• 1521 views

Because experience with many compilers that attempt this stratgey has shown that a syntax error can itself cause subsequent errors. If you fix the first error then the other errors are magically not there anymore, thus indicating that false or unnecessary error messages were displayed. So, nowadays with our much faster edit-parse cycles, it is more efficient to report on the first serious error and stop further parsing until that is fixed.

I have fond memories of compiling COBOL programs that will report pages and pages of errors because I mispelled "WORKING-STORAGE SECTION." or left out the "ID DIVISION".

Euphoria, both v3 and v4 are doing better by stopping on the first serious error.

41. Re: buggy 4.0 program

• Posted by SDPringle Dec 15, 2008
• 1612 views

a 
puts(1,"test") 

If you just want the facts, the error should read "incomplete statement."

a.ex:1 
Syntax error - incomplete statement 
a 
^ 
 
 
Press Enter 

a = 1 
puts(1,"test") 

Here it is more desirable to see: "a has not been declared" or the 4.0 "undefined references".

Shawn Pringle

43. Re: buggy 4.0 program

• Posted by jimcbrown (admin) Dec 15, 2008
• 1554 views

This boils down to the text of the error message that is shown. I don't really care which version ("Please declare" or "Unresolved forward references") is used.

Which is?

This is really complicated, as some errors leave the parser's state machine in a weird or undefined state.

45. Re: buggy 4.0 program

• Posted by DerekParnell (admin) Dec 16, 2008
• 1531 views

You are wrong. Variables can be referenced before they are declared.

Now you're just being silly.

47. Re: buggy 4.0 program

• Posted by bernie Dec 16, 2008
• 1540 views

Hi Igor:
If you try writing programs with version 4.0;
you will find how valuable the new forward reference is.
It eliminates the need for move routines around in your code.
It eliminates the need for using some routine_id's in your code.
Before you question it, try using it in your code, You will like it.
Sometimes us old men have to change our ways.
Bernie

49. Re: buggy 4.0 program

• Posted by DerekParnell (admin) Dec 16, 2008
• 1530 views

[quote DerekParnell]

integer a = 1 
? a 

Just kidding ..... try this instead ...

-- file: foo.e -- 
public integer a = 1 
---- 

-- file: text.ex -- 
procedure xyz() 
integer a = 1 
end procedure 
 
 
xyz() 
 
include foo.e 
 

Currently, a forward declared variable must be declared in another file and can only be referenced inside a routine. These restriction may change.

51. Re: buggy 4.0 program

• Posted by Spock Dec 17, 2008
• 1511 views

Does 4.0 actually allow routines in a file to be invoked before they are declared?

regards, Spock

53. Re: buggy 4.0 program

• Posted by kinz Dec 17, 2008
• 1525 views

Ok, Bernie, I'll try to learn the new features and use them

Regards,
Igor Kachan
kinz@peterlink.ru

55. Re: buggy 4.0 program

• Posted by DerekParnell (admin) Dec 17, 2008
• 1512 views

Currently, forward references do not apply to namespace identifiers. This may change.