bearophile schrieb:
> Walter:
> 
>> Only because clang made a marketing issue out of it. Nobody coming from dmc++
>> noticed.
>>
>> I used to point out this feature in dmc++ to users. Nobody cared, I'd just get
>> blank looks. Why would I drop it if people wanted it?
> 
> Maybe it's all just marketing. But sometimes marketing is also a form of education, it teaches people a new way to do something, or why they should care about something.
> 
> Another possibity is that maybe the ecosystem around a language is changed, today more people use an IDE (especially people that don't use C/C++), and if you are using an IDE then maybe it is an useful feature.
> 
> Probably reality is a mix of those different possibilities.
> 
> 
>> Clang did have a nice idea with the spelling corrector. I implemented it in dmc
>> and dmd, and got flak for "wasting time" by adding it. I still like it, though,
>> and think it's an improvement :-)
> 
> In my opinion too it's an improvement. I presume some people have said it was a "waste of time" because currently there are more important issues/bugs in DMD.
> 
> 
> In the meantime I have underlined a second small idea from Clang that I think will be useful to implement in D/DMD too, the use of "aka", this is an example from Clang:
> 
> t.c:13:9: error: member reference base type 'pid_t' (aka 'int') is not a
> structure or union
> 
> 
> This is a wrong D2 program: 
> 
> 
> void main() {
>     alias int Foo;
>     Foo f;
>     f = f.x;
> }
> 
> 
> DMD 2.049 prints:
> test.d(4): Error: no property 'x' for type 'int'
> 
> But a more useful error message may be:
> test.d(4): Error: no property 'x' for type 'Foo' (aka 'int')
> 
> In a tiny program like that the difference doesn't show much, but as programs get bigger, and alias is more far from its usage, it will be useful.
> 
> The enhancement request:
> http://d.puremagic.com/issues/show_bug.cgi?id=5004
> 
> Bye,
> bearophile

It's not just the aka that would be really helpful here, but especially the "type Foo" instead of "type int".
Sometimes you have aliased types you use without really thinking too much about their real type, like FILE, socket_t and stuff like that.
So when you get an error-message talking about int or something and your code says socket_t it may be harder to find the error - especially when you have got multiple variables of different types in one line.
Of course getting information about types (the "logical" type like socket_t and the original type like int) in the error-message like in bearophiles "aka" suggestion would be the best solution :)

Dmitry Olshansky, el 26 de octubre a las 12:54 me escribiste:
> On 26.10.2010 7:42, Walter Bright wrote:
> >Rainer Deyke wrote:
> >>On 10/25/2010 19:01, Walter Bright wrote:
> >>>Yes, we discussed it before. The Digital Mars C/C++ compiler does this,
> >>>and NOBODY CARES.
> >>>Not one person in 25 years has ever even commented on it. Nobody
> >>>commented on its lack in dmd.
> >>
> >>I think someone just did.
> >
> >Only because clang made a marketing issue out of it. Nobody coming from dmc++ noticed.
> >
> >I used to point out this feature in dmc++ to users. Nobody cared, I'd just get blank looks. Why would I drop it if people wanted it?
> >
> >Clang did have a nice idea with the spelling corrector. I implemented it in dmc and dmd, and got flak for "wasting time" by adding it. I still like it, though, and think it's an improvement :-)
> I actually like this  spell-checking thing. It was of great help to me, especially while I was just learning D, all those new funny function names...

I'm looking to you, Andrei!!!

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Y ya no tengo colores, sólo gris y negro
Aquí donde el amor es de hierro
Los días pasan y moriremos contando el tiempo

On 10/26/10 9:07 CDT, Leandro Lucarella wrote:
> Dmitry Olshansky, el 26 de octubre a las 12:54 me escribiste:
>> On 26.10.2010 7:42, Walter Bright wrote:
>>> Rainer Deyke wrote:
>>>> On 10/25/2010 19:01, Walter Bright wrote:
>>>>> Yes, we discussed it before. The Digital Mars C/C++ compiler does this,
>>>>> and NOBODY CARES.
>>>>> Not one person in 25 years has ever even commented on it. Nobody
>>>>> commented on its lack in dmd.
>>>>
>>>> I think someone just did.
>>>
>>> Only because clang made a marketing issue out of it. Nobody coming
>> >from dmc++ noticed.
>>>
>>> I used to point out this feature in dmc++ to users. Nobody cared,
>>> I'd just get blank looks. Why would I drop it if people wanted it?
>>>
>>> Clang did have a nice idea with the spelling corrector. I
>>> implemented it in dmc and dmd, and got flak for "wasting time" by
>>> adding it. I still like it, though, and think it's an improvement
>>> :-)
>> I actually like this  spell-checking thing. It was of great help to
>> me, especially while I was just learning D, all those new funny
>> function names...
>
> I'm looking to you, Andrei!!!

I'm ducking.

Andrei

Walter Bright wrote:
> bearophile wrote:
>>> "acts very badly" kinda means the same thing :-)
>>
>> DMD acts very badly regarding that specific situation,
> 
> As I said, the two error messages it gives are right on target.

	"AssertionFailure: 'tn->mod == MODimmutable' on line 879 in file
'mtype.c'" is "right on target" when compiling a D source file?? I'd
hate to see a message you consider bad ;)

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

Jacob Carlborg wrote:
> That is what the whole thread is about, giving better and more accurate error messages. A great example, as bearophile shows, is the missing semicolon error which Clang points to the "right" line wheres DMD, GCC points to the start of the next statement. As Walter points out this is syntactical correct since there is no correct position for the semicolon in a whitespace indepdent language but I still think bearophile is correct in this case.
> 
	Of course, with C it is even worse since the place gcc points to
may not even be in the right *file*...

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

Jérôme M. Berger wrote:
> Walter Bright wrote:
>> bearophile wrote:
>>>> "acts very badly" kinda means the same thing :-)
>>> DMD acts very badly regarding that specific situation,
>> As I said, the two error messages it gives are right on target.
> 
> 	"AssertionFailure: 'tn->mod == MODimmutable' on line 879 in file
> 'mtype.c'" is "right on target" when compiling a D source file?? I'd
> hate to see a message you consider bad ;)

As I also said, that was a compiler bug, and I was referring to the two diagnostic messages preceding it.

Walter Bright wrote:
> Jérôme M. Berger wrote:
>> Walter Bright wrote:
>>> bearophile wrote:
>>>>> "acts very badly" kinda means the same thing :-)
>>>> DMD acts very badly regarding that specific situation,
>>> As I said, the two error messages it gives are right on target.
>>
>>     "AssertionFailure: 'tn->mod == MODimmutable' on line 879 in file
>> 'mtype.c'" is "right on target" when compiling a D source file?? I'd
>> hate to see a message you consider bad ;)
> 
> As I also said, that was a compiler bug, and I was referring to the two diagnostic messages preceding it.

	Yes, but I believe that the reason bearophile said "acts very
badly" is because of the assert, since the other two messages are
more or less the same as the clang message (albeit slightly more
verbose).

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

Jérôme M. Berger wrote:
> Walter Bright wrote:
>> Jérôme M. Berger wrote:
>>> Walter Bright wrote:
>>>> bearophile wrote:
>>>>>> "acts very badly" kinda means the same thing :-)
>>>>> DMD acts very badly regarding that specific situation,
>>>> As I said, the two error messages it gives are right on target.
>>>     "AssertionFailure: 'tn->mod == MODimmutable' on line 879 in file
>>> 'mtype.c'" is "right on target" when compiling a D source file?? I'd
>>> hate to see a message you consider bad ;)
>> As I also said, that was a compiler bug, and I was referring to the two
>> diagnostic messages preceding it.
> 
> 	Yes, but I believe that the reason bearophile said "acts very
> badly" is because of the assert, since the other two messages are
> more or less the same as the clang message (albeit slightly more
> verbose).

I don't agree, as the thread is about quality of error messages, not bugs in the compiler.

On 2010-10-25 22:21:01 -0400, bearophile <bearophileHUGS@lycos.com> said:

> Michel Fortin:
> 
>> I'd like it very much if dmd printed the column number
>> for the caret in addition to the line.
> 
> The C# compiler too show those column number. But last time Walter has explained that to do this, the compiler has to keep more data (all those line numbers), so this may slow down the compilation a little. And of course currently this information is not present, so it probably requires a good amount of changes to be implemented.

It's not that hard to implement. I did a custom version of the DMD frontend to do something similar for the early versions of D for Xcode. I needed to have the exact start and end location of each token expressed in character index from the beginning of the file. I used that for syntax highlighting.

To get column numbers in error messages, here's all I'd expect you need to do:

1. add a column field to the Loc struct (in mars.h)
2. make the lexer keep track of the current column
3. make error() print that field

Give it a try if you want.

Then you can do some benchmark to check how slower it is (probably nothing noticeable).

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On 26/10/2010 04:32, Walter Bright wrote:
> bearophile wrote:
>> The C# compiler too show those column number. But last time Walter has
>> explained that to do this, the compiler has to keep more data (all
>> those line
>> numbers), so this may slow down the compilation a little. And of course
>> currently this information is not present, so it probably requires a good
>> amount of changes to be implemented. The slowdown problem may be
>> solved as in
>> GCC, adding a compilation switch that gives/removes the column number (it
>> uses to be switched off on default, now after the competition by Clang
>> it's
>> switched on on default).
>
> Switching it off will have no effect on compile speed.
>

Why is that? What would cause a loss in compile speed even if this option was turned off?

-- 
Bruno Medeiros - Software Engineer