On 30/03/14 21:16, Walter Bright wrote:

> I've pointed out how to do this without ID's several times.

Are you willing to make the error messages public API? That would go through the same stages of deprecation when they need to change?

-- 
/Jacob Carlborg

On Friday, 28 March 2014 at 18:24:21 UTC, Walter Bright wrote:
> On 3/28/2014 2:37 AM, Andrea Fontana wrote:
>> There's another advantage. If you want to change error message (or add
>> localization like in visual c++) you still can found what the error means.
>
> Completely worthless:
>
> 1. Programmers program in English. Yes, I've asked many international shops about this. They want error messages in English.

Good to know. I don't like l10n of messages but many app simply use os default language. I hope it doesn't happen then.

>
> 2. The internationalized messages are *terrible* because you need a person who is fluent in that language, and in compilers, to write them. That just doesn't work out too well in practice.
> 3. Every time you add/change an error message to the compiler, then you have to go back to (2) and try to deal with that. Never works, or you get crappy translations, meaning (1) the foreign programmers again prefer the English messages.
> I.e. been there, done that. Translated messages are great for a lot of apps, but not for programming tools.
>

I agree with you about english and programming. My point was to show you that there are cases where error codes are useful. (however it's not that difficult to translate a message in your own native language)

>> It should be easier for IDE to parse and give suggestions or redirect to an help
>> page to solve the problem.
>
> The IDE doesn't have to parse them. All it has to do is do a substring search. The IDE developer would have to provide the patterns to search for, but that isn't any harder than creating an indexed table.

I disagree here.

1) If you want to google for error, you have to strip extra info (line, symbols, etc)

2) It happens that you search for an error and you find error from another compiler.

3) Error messages can be wrong or not well-written (they can contains typos). If you change their description to make them clear you have to change the pattern.
And if you want to change the format of error messages (let's say: add line/column/demangling symbols/giving hints/...) you'll probably brake ide parsers. It's quite different if IDE just needs to read the first word of line or first match "DPL[0-9]{5}".

4) Don't know if this is a case, but two errors can have similar descriptions and googling for an error could drive user to the wrong one

5) Why a central map "string code" => "error message" should be harder to mantain than a lot of messages putted around the source code?

On Sun, 30 Mar 2014 15:23:44 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 3/30/2014 4:04 AM, Paulo Pinto wrote:
>> Am 28.03.2014 19:09, schrieb Walter Bright:
>>> On 3/28/2014 2:23 AM, monarch_dodra wrote:
>>>> Well, I'm just throwing that out there.
>>>
>>> I've thought many times that an error message should be a clickable
>>> link. But until console displays support clickable text, it's just a
>>> fantasy.
>>
>> Actually on GNU/Linux systems many do.
>
> I just tried it on Ubuntu and - you're right! Pretty awesome.

Yes, I think a url, even if not clickable, is way more useful than an arbitrary error id. It takes not much effort to copy/paste a URL into a browser.

We can make this easy:

Compiler outputs a URL like this: http://derror.org/2.065/filename.c/l123

Using a function that takes __FILE__ and __LINE__

Then, include a special comment just before the error output that will be parsed by a post-processor, and link that url to the comment (either in github, or on a nice web page).

Example:

const char *errurl(const char *file = __FILE__, int line = __LINE__); // does this work in C++? I can't remember!

// <ERRMSG> A variable cannot be re-defined inside a new scope. See http://dlang.org/...
error("is shadowing declaration %s%s", s->toPrettyChars(), errurl());

errurl could be configured to print a URL or nothing via a command line option.

Bonus: those who know the error url format know exactly where to go in the code to see where it was printed from.

-Steve

Walter Bright <newshound2@digitalmars.com> wrote:
> On 3/28/2014 1:23 AM, Johannes Pfau wrote:
>> As an example how this could work, search for CS1002.
>> So do we want this?
> 
> I've done this before. Short answer, it's a pain and doesn't really help.
> 
> Searching is easy, just type in the message that was displayed, sans the variable part. I do it all the time.

I think some sort of short identifier for warnings and errors would be beneficial. It does not have to be a number.

Advantages not already mentioned:
- Messages can change/improve over time, the ID remains the same.
- Enable/disable warnings by ID.

And this would again enable tools to disable a warning e.g. by right-clicking on the actual message.

I imagine there are more similar tasks that can be done with only the ID
without actually knowing the meaning of the warning.
Like turning warnings into errors if you don't like the usecase of
disabling warnings.

Since you are already considering URLs in the messages, you need some kind of ID anyway, otherwise you couldn't build an URL.

Tobi

On 3/31/2014 5:10 AM, Steven Schveighoffer wrote:
> We can make this easy:

The trouble with outputting URLs is that they will be significant visual noise to the user.

Yeah, I know, another compiler switch :-)

On Mon, 31 Mar 2014 13:02:48 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 3/31/2014 5:10 AM, Steven Schveighoffer wrote:
>> We can make this easy:
>
> The trouble with outputting URLs is that they will be significant visual noise to the user.
>
> Yeah, I know, another compiler switch :-)

Yeah, so?

-Steve

On 3/31/2014 12:47 AM, Andrea Fontana wrote:
> I disagree here.
>
> 1) If you want to google for error, you have to strip extra info (line, symbols,
> etc)

Copy-paste with a mouse. The same thing you'd do for a message id number.


> 2) It happens that you search for an error and you find error from another
> compiler.

I explained to bearophile in this thread how to do site-specific searches with google.


> 3) Error messages can be wrong or not well-written (they can contains typos). If
> you change their description to make them clear you have to change the pattern.
> And if you want to change the format of error messages (let's say: add
> line/column/demangling symbols/giving hints/...) you'll probably brake ide
> parsers. It's quite different if IDE just needs to read the first word of line
> or first match "DPL[0-9]{5}".

Come on, this is not rocket science.


> 4) Don't know if this is a case, but two errors can have similar descriptions
> and googling for an error could drive user to the wrong one

Yes, and you can mistype the message number, too.


> 5) Why a central map "string code" => "error message" should be harder to
> mantain than a lot of messages putted around the source code?

Because not having a map is easier to maintain than having one.

On 2014-03-31 19:02, Walter Bright wrote:

> The trouble with outputting URLs is that they will be significant visual
> noise to the user.

It would be great for those IDE's and text editors that use HTML as output format.

-- 
/Jacob Carlborg