Re: type error formatting

[Joachim Breitner]

Hi,

Am Samstag, den 24.10.2015, 13:14 -0700 schrieb Evan Laforge:
> WRT the "bound at" bits in "relevant bindings", I have no strong
> opinion.  What about omitting them if they are in the same file as
> the main error?  Or maybe they always are?  I'm not totally clear how
> it chooses which bindings are relevant.

take one step at a time, and fix the issue you are having within
#11014. Once that is through and merged, then (or in parallel to)
trying to trim down the bound-at messages can be attempted.

Am Samstag, den 24.10.2015, 22:30 +0200 schrieb MigMit:
> At the very least, "bound at" should help IDEs (Emacs in particular)
> show exactly the right places.

an IDE that offers such a deep integration will hopefully not parse
data meant for human consumption. We have had this discussion before
(in the context of avoiding or merging multiple instances of the same
error message, such as “foo not in scope”), and I continue to argue
that the error messages printed by default should be tailored for the
human reader.

IDEs should ideally make use of something based on the GHC API. If that
is not possible, then I’d advocate a flag, say "-fverbose-error-
messages" or similar that includes all detail that might be relevant
for an IDE, and maybe even in a nicer-to-parse format.

Greetings,
Joachim


-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org



signature.asc
Description: This is a digitally signed message part
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: type error formatting

[MigMit]

> On 25 Oct 2015, at 21:21, Joachim Breitner  wrote:
> 
> Am Samstag, den 24.10.2015, 22:30 +0200 schrieb MigMit:
>> At the very least, "bound at" should help IDEs (Emacs in particular)
>> show exactly the right places.
> 
> an IDE that offers such a deep integration will hopefully not parse
> data meant for human consumption.

Hope is good. Reality, however, is different. At least haskell-mode in Emacs 
DOES parse such data, when you try to load your file in REPL.

> IDEs should ideally make use of something based on the GHC API.

I agree. But the key word here is "ideally".

Second thought though — do we really want to create a gap between error 
messages from the compiler and whatever IDE tells us? After all, text output 
from GHC is ALSO a kind of API.

> If that
> is not possible, then I’d advocate a flag, say "-fverbose-error-
> messages" or similar that includes all detail that might be relevant
> for an IDE, and maybe even in a nicer-to-parse format.

Doesn't seem worth it to me. Current format is quite parseable, and not really 
bad for human eyes either.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: type error formatting

[Joachim Breitner]

Hi,

Am Sonntag, den 25.10.2015, 21:30 +0100 schrieb MigMit:
> Doesn't seem worth it to me. Current format is quite parseable, and
> not really bad for human eyes either.

I know that you meant this as a litote, but let me ignore that I know
that for a moment to reply, that “not really bad” is definitely not
good enough for me, and I want the compiler to print messages that are
meant for my consumption to be in the _best_ possible format. Or at
least try that.

Obviously, there is no “best” for every human. But things get easier if
we do not have to overly worry about computers as well.

It goes the other way as well. IDEs would tremendously benefit if the
error location would not just be a position but a whole span. But
clearly (I hope) we do not want to include this information in the
output that we read.

BTW, does Emacs really parse _this_ bit of information? Most GHC
integrations that I have seen match on the first line to indicate the
file and position of the overall error, and take the error verbatim.

Greetings,
Joachim


-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org



signature.asc
Description: This is a digitally signed message part
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: type error formatting

[MigMit]

> On 25 Oct 2015, at 21:45, Joachim Breitner  wrote:
> 
> Hi,
> 
> Am Sonntag, den 25.10.2015, 21:30 +0100 schrieb MigMit:
>> Doesn't seem worth it to me. Current format is quite parseable, and
>> not really bad for human eyes either.
> 
> I know that you meant this as a litote,

Please, don't say "know" when you mean "assume". It's especially annoying when 
you assume wrong.

> but let me ignore that I know
> that for a moment to reply, that “not really bad” is definitely not
> good enough for me, and I want the compiler to print messages that are
> meant for my consumption to be in the _best_ possible format. Or at
> least try that.
> 
> Obviously, there is no “best” for every human. But things get easier if
> we do not have to overly worry about computers as well.

I think that's a wrong approach.

My theory is that the concepts "easy to read for a human with some experience" 
and "easy to parse for a computer" are two closely related notions.

Sure, they aren't identical — a binary format might still be quite easy to 
parse, but completely unreadable for human — but they go hand in hand. Even 
with binary formats — if, for example, there is a clear notion of "statement" 
in this binary formats, and statements are separated by the byte "0xff", it's 
easier both for a human (equipped with binary editor) and for a computer than, 
for example, if the length of the statement is determined by the first byte.

But! It's much easier to argue about "what's easier for a computer" than the 
same thing for humans.

> BTW, does Emacs really parse _this_ bit of information? Most GHC
> integrations that I have seen match on the first line to indicate the
> file and position of the overall error, and take the error verbatim.

Last time I checked, Emacs transformed such positions into hyperlinks.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users