On 3/29/2014 11:02 AM, Brad Anderson wrote:
> For example, in VC++ if you get "C2001 newline in constant" you
> can just lookup C2001
> http://msdn.microsoft.com/en-us/library/4x3c2e37.aspx

Or you could look up "newline in constant".

My point is there's nothing magical about using a number instead. It simply does not enable new features that aren't already there.

Walter Bright:

> On 3/29/2014 11:02 AM, Brad Anderson wrote:
>> For example, in VC++ if you get "C2001 newline in constant" you
>> can just lookup C2001
>> http://msdn.microsoft.com/en-us/library/4x3c2e37.aspx
>
> Or you could look up "newline in constant".

If I search this:
C2001 newline in constant

I see the Microsoft page as first Google result:
http://msdn.microsoft.com/en-us/library/4x3c2e37.aspx

If I search this:
newline in constant

The desired Microsoft page is not in the first page of ten results given by Google. The third link it to a not correct page:
http://support.microsoft.com/kb/827420

(And still, I have not seen addressed the psychological point I have explained in a precedent post).

Bye,
bearophile

On Sat, Mar 29, 2014 at 12:00:51PM -0700, Walter Bright wrote:
> On 3/29/2014 11:02 AM, Brad Anderson wrote:
> >For example, in VC++ if you get "C2001 newline in constant" you can just lookup C2001 http://msdn.microsoft.com/en-us/library/4x3c2e37.aspx
> 
> Or you could look up "newline in constant".
> 
> My point is there's nothing magical about using a number instead. It simply does not enable new features that aren't already there.

I think there's merit in using an error number. It allows easier programmatic processing, for example. An IDE might want to detect certain error numbers and give some more specific user feedback or suggest possible fixes.

While you *could* do the same with just a string lookup, that's unstable because presumably, compiler error messages would be improved every now and then, and you don't want a simple rephrasing of the error to require updating every single IDE and other tool just to match the new wording of the same error.

Also, not every error needs a separate number; some parts of the compiler may generate different error messages for what is essentially the same underlying problem (this may depend on the specific evaluation order of the erroneous input, for example). By assigning a single error number for both messages, you can aid automated processing tools like IDEs to treat a variety of messages as a single logical problem that can be uniformly handled.

To do the same using string lookups will require unnecessary additional effort on the part of the IDE/tool implementor. (And it would break as soon as a PR that improves compiler error messages gets pulled.)


T

-- 
VI = Visual Irritation

On 3/29/2014 12:07 PM, bearophile wrote:
> Walter Bright:
>
>> On 3/29/2014 11:02 AM, Brad Anderson wrote:
>>> For example, in VC++ if you get "C2001 newline in constant" you
>>> can just lookup C2001
>>> http://msdn.microsoft.com/en-us/library/4x3c2e37.aspx
>>
>> Or you could look up "newline in constant".
>
> If I search this:
> C2001 newline in constant
>
> I see the Microsoft page as first Google result:
> http://msdn.microsoft.com/en-us/library/4x3c2e37.aspx
>
> If I search this:
> newline in constant
>
> The desired Microsoft page is not in the first page of ten results given by
> Google. The third link it to a not correct page:
> http://support.microsoft.com/kb/827420

Or you could:

  visual studio 2013 error newline in constant

or:

  msdn error newline in constant

or even better:

  "newline in constant" site:microsoft.com

This is pretty basic google-fu


> (And still, I have not seen addressed the psychological point I have explained
> in a precedent post).

I did, specifically.

On 3/29/2014 1:11 PM, H. S. Teoh wrote:
> I think there's merit in using an error number. It allows easier
> programmatic processing, for example.

    strstr(s,"C2001")

is not any easier than:

    strstr(s, "newline in constant")


> An IDE might want to detect
> certain error numbers and give some more specific user feedback or
> suggest possible fixes.

Sure. But numbers are hardly necessary for that.


> While you *could* do the same with just a string lookup,

And it's trivial to do so. No extra work at all. See strstr() above.


> that's unstable
> because presumably, compiler error messages would be improved every now
> and then, and you don't want a simple rephrasing of the error to require
> updating every single IDE and other tool just to match the new wording
> of the same error.

Sorry, even with numbers, you gotta go fix the strings everywhere. After all, the user would be quite confused if he saw different error messages under "C2001" in the documentation than coming from his compiler.

And besides, this DRY problem was solved decades ago. Have a common file from which all message texts are drawn.


> Also, not every error needs a separate number; some parts of the
> compiler may generate different error messages for what is essentially
> the same underlying problem (this may depend on the specific evaluation
> order of the erroneous input, for example). By assigning a single error
> number for both messages, you can aid automated processing tools like
> IDEs to treat a variety of messages as a single logical problem that can
> be uniformly handled.

I suggest a simple solution:

   if (A || B) { ... common handler code ... }


> To do the same using string lookups will require unnecessary additional
> effort on the part of the IDE/tool implementor. (And it would break as
> soon as a PR that improves compiler error messages gets pulled.)

I've done error numbers before. It is not less effort - it's more - and it's ugly visual noise to the user as well. It's a 1980's solution, forced more or less because memory was incredibly tight and I/O was incredibly slow.

Walter Bright:

>> (And still, I have not seen addressed the psychological point I have explained in a precedent post).
>
> I did, specifically.

Sorry, I didn't see it.

Bye,
bearophile

I agree with Walter here. Maintaining error numbers for all errors would require not little cost for compiler code and documentations, AND it will slow down compiler improvements for more better diagnostic messages so we would need to keep backward compatibility of error numbers.

I'll refuse to maintain error number feature.

Kenji Hara

2014-03-30 5:11 GMT+09:00 H. S. Teoh <hsteoh@quickfur.ath.cx>:

> On Sat, Mar 29, 2014 at 12:00:51PM -0700, Walter Bright wrote:
> > On 3/29/2014 11:02 AM, Brad Anderson wrote:
> > >For example, in VC++ if you get "C2001 newline in constant" you can just lookup C2001 http://msdn.microsoft.com/en-us/library/4x3c2e37.aspx
> >
> > Or you could look up "newline in constant".
> >
> > My point is there's nothing magical about using a number instead. It simply does not enable new features that aren't already there.
>
> I think there's merit in using an error number. It allows easier programmatic processing, for example. An IDE might want to detect certain error numbers and give some more specific user feedback or suggest possible fixes.
>
> While you *could* do the same with just a string lookup, that's unstable because presumably, compiler error messages would be improved every now and then, and you don't want a simple rephrasing of the error to require updating every single IDE and other tool just to match the new wording of the same error.
>
> Also, not every error needs a separate number; some parts of the compiler may generate different error messages for what is essentially the same underlying problem (this may depend on the specific evaluation order of the erroneous input, for example). By assigning a single error number for both messages, you can aid automated processing tools like IDEs to treat a variety of messages as a single logical problem that can be uniformly handled.
>
> To do the same using string lookups will require unnecessary additional effort on the part of the IDE/tool implementor. (And it would break as soon as a PR that improves compiler error messages gets pulled.)
>
>
> T
>
> --
> VI = Visual Irritation
>

On 3/29/2014 8:50 PM, Kenji Hara wrote:
> I'll refuse to maintain error number feature.

:-)

On 03/29/2014 02:53 PM, Walter Bright wrote:
> On 3/29/2014 10:12 AM, froglegs wrote:
>> Having the error number is very
>> useful for googling(yes the complete message will give you hits,
>> but the # is more concise and turns up more hits),
> 
> More hits? How is that possible?
> 
> 
> 
For starters, having a URL such as http://dlang.org/error/D123 is
instantly recognizable, so when users see a DXYZ error code before and
remember that they ended up on http://dlang.org/error/DXYZ, they'll be
more likely to remember. (I'm looking at you, MSDN pages with
impossible-to-remember URLs) This way, the user will eventually just
skip the search engine altogether and just go directly to the error's page.

-- 
Matt Soucy
http://msoucy.me/

"Matt Soucy"  wrote in message news:lh8nkd$mst$1@digitalmars.com...

> For starters, having a URL such as http://dlang.org/error/D123 is
> instantly recognizable, so when users see a DXYZ error code before and
> remember that they ended up on http://dlang.org/error/DXYZ, they'll be
> more likely to remember. (I'm looking at you, MSDN pages with
> impossible-to-remember URLs) This way, the user will eventually just
> skip the search engine altogether and just go directly to the error's page.

Building a compiler for people who can't google is like building a race track for people who can't drive.