I like D very much, but when I'm writing code I spend too much time thinking about "what does this error message means". This problem is common for a lot of compilers, but D - as a rather new language - makes me even more confused sometimes because I'm not used to it.

Let's say I've just:

foreach(int b, _bogus) {
    b=1;
}

and DMD gives me:

: no identifier for declarator

I've started to look for typos in naming and such when actually I've used ',' where ';' was needed. I know this is my fault and this mistake means lack of wisdom and itss rather easy to find. But it would be perfect if D compiler could give hints for such common mistakes. It wouldn't interrupt or even slower normal parsing and similar. DMD could just take line with error at the end of parsing process and compare it with some regular expresions. It could be even a command line switch -ne (noob errors) or something like this.

What do you think?
-- 
Dawid Ciężarkiewicz | arael
jid: arael@fov.pl

Dawid Ciężarkiewicz wrote:

> Let's say I've just:
> 
> foreach(int b, _bogus) {
>     b=1;
> }
> 
> and DMD gives me:
> 
> : no identifier for declarator

Funny, the GDC compiler instead says: (v0.8)

>  found ')' when expecting ';'

(both should be pointing to the line, which
some IDEs can use to highlight the error...)


Better error messages could come later, at this
point it is mostly 1) fixing D bugs 2) giving errors
in the first place, instead of throwing assertions :-)

But some more sample code, with suggestions for better
error messages than the current ones, would be nice ?

--anders

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dawid schrieb am Thu, 16 Dec 2004 10:04:51 +0100:
> I like D very much, but when I'm writing code I spend too much time thinking about "what does this error message means". This problem is common for a lot of compilers, but D - as a rather new language - makes me even more confused sometimes because I'm not used to it.
>
> Let's say I've just:
>
> foreach(int b, _bogus) {
>     b=1;
> }
>
> and DMD gives me:
>
>: no identifier for declarator
>
> I've started to look for typos in naming and such when actually I've used ',' where ';' was needed.

Enhancing "lexer.c" and the various "::error(const char *format, ...)" should allow the compiler to print the line number and the position within the line that caused the error.

By adding a rescan function to the various "::error(const char *format, ...)"
it might be possible to print the actual content of the line and mark
the trouble spot.

Potential problem:
- - Lexer::peek(Token *ct)
- - trans-module errors

> I know this is my fault and this mistake means
> lack of wisdom and itss rather easy to find. But it would be perfect if D
> compiler could give hints for such common mistakes. It wouldn't interrupt
> or even slower normal parsing and similar. DMD could just take line with
> error at the end of parsing process and compare it with some regular
> expresions. It could be even a command line switch -ne (noob errors) or
> something like this.

I'm unsure about your "regular expression" suggestion.

Surely, the error messages could be improved, e.g.
"no identifier for declarator '_bogus'" instead of
"no identifier for declarator".

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFBwVxV3w+/yD4P9tIRApRNAJ9f+6JA0qoik6oEWOpwYib8V1gh1ACgil5K
om4vbBkLxEXLr5EswyH9gds=
=qC08
-----END PGP SIGNATURE-----

Anders F Björklund wrote:

> (both should be pointing to the line, which
> some IDEs can use to highlight the error...)

DMD is pointing to the line - I've just erased the line number that was right before ':'.

> Better error messages could come later, at this
> point it is mostly 1) fixing D bugs 2) giving errors
> in the first place, instead of throwing assertions :-)

Yes. There is many more important things. :)

> But some more sample code, with suggestions for better error messages than the current ones, would be nice ?

I'll try to give some examples soon. The problem with finding examples of "stupid mistakes" is that you have to make such a mistake first. But it's rather easy for me so... :D



For now the "you forgot the ';' after previous line" and checking the keywords environment (for commas, {} blocks, ";" and such) is what comes to my mind. Maybe there is too less such a places when this whole idea could be used. But maybe someone else was thinking about something similar before, when he was looking at his code after many hours of work and couldn't find "so simple mistake" for a long time.
-- 
Dawid Ciężarkiewicz | arael
jid: arael@fov.pl

In article <cprj3m$1l8g$1@digitaldaemon.com>, Dawid =?ISO-8859-2?Q?Ci=EA=BFarkiewicz?= says...
>
>I like D very much, but when I'm writing code I spend too much time thinking about "what does this error message means". This problem is common for a lot of compilers, but D - as a rather new language - makes me even more confused sometimes because I'm not used to it.

While we're waiting for Walter to fix the bugs, we can make on own list. Here's a start: http://www.prowiki.org/wiki4d/wiki.cgi?ErrorMessages

jcc7

"Dawid Ciê¿arkiewicz" <arael@fov.pl> wrote in message news:cprj3m$1l8g$1@digitaldaemon.com...
> I like D very much, but when I'm writing code I spend too much time
thinking
> about "what does this error message means". This problem is common for a lot of compilers, but D - as a rather new language - makes me even more confused sometimes because I'm not used to it.
>
> Let's say I've just:
>
> foreach(int b, _bogus) {
>     b=1;
> }
>
> and DMD gives me:
>
> : no identifier for declarator
>
> I've started to look for typos in naming and such when actually I've used ',' where ';' was needed. I know this is my fault and this mistake means lack of wisdom and itss rather easy to find. But it would be perfect if D compiler could give hints for such common mistakes. It wouldn't interrupt or even slower normal parsing and similar. DMD could just take line with error at the end of parsing process and compare it with some regular expresions. It could be even a command line switch -ne (noob errors) or something like this.
>
> What do you think?

I think you're right. D error messages do need improvement, and they are gradually getting better.

the problem i had with "null is not an lvalue" is exactly
that kind of message. i had no clue what went wrong.
only by accident i came to see that it's the unneeded
"const" declaration that caused the error.

i agree, better error messages would produce healthier code, and as well would help newbies to learn the language..

- Asaf.

"Dawid Ciê¿arkiewicz" <arael@fov.pl> wrote in message news:cprmf1$1p3a$1@digitaldaemon.com...
> Anders F Björklund wrote:
>
>> (both should be pointing to the line, which
>> some IDEs can use to highlight the error...)
>
> DMD is pointing to the line - I've just erased the line number that was right before ':'.
>
>> Better error messages could come later, at this
>> point it is mostly 1) fixing D bugs 2) giving errors
>> in the first place, instead of throwing assertions :-)
>
> Yes. There is many more important things. :)
>
>> But some more sample code, with suggestions for better error messages than the current ones, would be nice ?
>
> I'll try to give some examples soon. The problem with finding examples of "stupid mistakes" is that you have to make such a mistake first. But it's rather easy for me so... :D
>
>
>
> For now the "you forgot the ';' after previous line" and checking the
> keywords environment (for commas, {} blocks, ";" and such) is what comes
> to
> my mind. Maybe there is too less such a places when this whole idea could
> be used. But maybe someone else was thinking about something similar
> before, when he was looking at his code after many hours of work and
> couldn't find "so simple mistake" for a long time.
> -- 
> Dawid Ciê¿arkiewicz | arael
> jid: arael@fov.pl

In article <cpunfm$25s5$1@digitaldaemon.com>, Asaf Karagila says...
>
>the problem i had with "null is not an lvalue" is exactly
>that kind of message. i had no clue what went wrong.
>only by accident i came to see that it's the unneeded
>"const" declaration that caused the error.

Yes, although exceptional in D, this particular example reminds
me of C++ compiler error messages: even in the unlikely
event that they happen to refer to the right line number,
chances are that the subject of the lament is off by miles.

>i agree, better error messages would produce healthier code, and as well would help newbies to learn the language..

Not only that. Established D programmers would waste less time debugging, newbies would learn the language a lot faster, Real Gurus would find their (rare trivial) mistakes faster.

>>> Better error messages could come later, at this
>>> point it is mostly 1) fixing D bugs 2) giving errors
>>> in the first place, instead of throwing assertions :-)

Agreed. But at 1.0 we really have to have a compiler that gives unambiguous error messages, hits the line, and the messages will be (A LOT) more informative than "null is not an lvalue".

Actually something like a "-newbie" compiler switch might not be such a bad idea. This should not imply cheesy patronizing, rather it should be aimed towards an average (professional?) programmer, who just happens to be new to D.

Two things multiply the rate of expansion of D: (1) how fast people get confident with the compiler, and (2) how fast a programmer "outputs" valid, bug and error free code. (Equals Productivity!)

Score 0.5 in both, and you've quartered the success of D.

>>> But some more sample code, with suggestions for better error messages than the current ones, would be nice ?

This might be one perfect thing to load off Walter's back!?

>> I'll try to give some examples soon. The problem with finding examples of "stupid mistakes" is that you have to make such a mistake first. But it's rather easy for me so... :D

Actually, a job that even a D-newbie (who is not pathetically over- worked, like most of us here) could do, and thence make a major contribution to D -- would be to take (say) the wc-example in the docs, and just deliberately make typos (like omitting a ";", misspelling a keyword, skipping or using an extra parenthesis somewhere), change types, declarations, etc. etc.

The ensuing error messages could be explained in such an article.

Ideally this should be written by somebody who's not used D for too long, because then one tends to become "home blind" and forget what the really hard issues, and tough parts were.

Georg Wrede wrote:
> In article <cpunfm$25s5$1@digitaldaemon.com>, Asaf Karagila says...
> 
...
>>>>Better error messages could come later, at this
>>>>point it is mostly 1) fixing D bugs 2) giving errors
>>>>in the first place, instead of throwing assertions :-)
> 
> 
> Agreed. But at 1.0 we really have to have a compiler that gives
> unambiguous error messages, hits the line, and the messages
> will be (A LOT) more informative than "null is not an lvalue".

Since I want D 1.0 release sometime /this decade/, it'd be acceptable to me if "null is not an lvalue" isn't improved until later. Perhaps you meant to say "at 10.0"?

What I've tried to do when I've found what I thought was a particularly horrible error message is to post the message (and code to produce it and maybe a suggestion) to the bugs newsgroup. I don't know if Walter plans on making my suggested improvements, but I at least feel better for registering the complaint.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

On Thu, 16 Dec 2004 15:12:17 -0800, Walter <newshound@digitalmars.com> wrote:

>
> "Dawid Ciê¿arkiewicz" <arael@fov.pl> wrote in message
> news:cprj3m$1l8g$1@digitaldaemon.com...
>> I like D very much, but when I'm writing code I spend too much time
> thinking
>> about "what does this error message means". This problem is common for a
>> lot of compilers, but D - as a rather new language - makes me even more
>> confused sometimes because I'm not used to it.
>>
>> Let's say I've just:
>>
>> foreach(int b, _bogus) {
>>     b=1;
>> }
>>
>> and DMD gives me:
>>
>> : no identifier for declarator
>>
>> I've started to look for typos in naming and such when actually I've used
>> ',' where ';' was needed. I know this is my fault and this mistake means
>> lack of wisdom and itss rather easy to find. But it would be perfect if D
>> compiler could give hints for such common mistakes. It wouldn't interrupt
>> or even slower normal parsing and similar. DMD could just take line with
>> error at the end of parsing process and compare it with some regular
>> expresions. It could be even a command line switch -ne (noob errors) or
>> something like this.
>>
>> What do you think?
>
> I think you're right. D error messages do need improvement, and they are
> gradually getting better.
>
>

Walter, Am I correct in my assumption that it is currently not possible for
an end-user to build DMD? It might help in cases like this a bit if people can
actually make it work better, and see that they didn't screw up. (I know (DMC/
legal issues?) you don't want to distro the backend source, but maybe it
precompiled as a lib or something?)

-- 
"Unhappy Microsoft customers have a funny way of becoming Linux,
Salesforce.com and Oracle customers." - www.microsoft-watch.com:
"The Year in Review: Microsoft Opens Up"
--
"I plan on at least one critical patch every month, and I haven't been disappointed."
- Adam Hansen, manager of security at Sonnenschein Nath & Rosenthal LLP
(Quote from http://www.eweek.com/article2/0,1759,1736104,00.asp)
--
"It's been a challenge to "reteach or retrain" Web users to pay for content, said Pizey"
-Wired website: "The Incredible Shrinking Comic"