[m-dev.] preferences for error contexts

[Paul Bone]

On Fri, May 15, 2009 at 02:55:50PM +1000, Peter Wang wrote:
> Hi,
> 
> We have some ugly error messages due to the way we use mmc -f, where
> the filename and line number context ends up taking up most of the screen
> width (don't ask).  Something like this:
> 
> /home/pwa/Work/gws_shorter_errors/extras/moose/lalr.m:535: In clause for
> /home/pwa/Work/gws_shorter_errors/extras/moose/lalr.m:535:   predicate
> /home/pwa/Work/gws_shorter_errors/extras/moose/lalr.m:535:   `propagate3'/7:
> /home/pwa/Work/gws_shorter_errors/extras/moose/lalr.m:535:   in argument 3 of
> /home/pwa/Work/gws_shorter_errors/extras/moose/lalr.m:535:   call to predicate
> /home/pwa/Work/gws_shorter_errors/extras/moose/lalr.m:535:   `map.search'/3:
> /home/pwa/Work/gws_shorter_errors/extras/moose/lalr.m:535:   type error:
> /home/pwa/Work/gws_shorter_errors/extras/moose/lalr.m:535:   variable `I' has
> /home/pwa/Work/gws_shorter_errors/extras/moose/lalr.m:535:   type
> /home/pwa/Work/gws_shorter_errors/extras/moose/lalr.m:535:
> `(set.set((lalr.item)))',
> /home/pwa/Work/gws_shorter_errors/extras/moose/lalr.m:535:   expected type was
> /home/pwa/Work/gws_shorter_errors/extras/moose/lalr.m:535:
> `(tree234.tree234((lalr.item),
> /home/pwa/Work/gws_shorter_errors/extras/moose/lalr.m:535:
> (set.set((grammar.terminal)))))'.
> 
> 
> I have a change that prints the context only on the first line.
> The output ends up like:
> 
> /home/pwa/Work/gws_shorter_errors/extras/moose/lalr.m:535: In clause for
>   predicate `propagate3'/7:
>   in argument 3 of call to predicate `map.search'/3:
>   type error:
>   variable `I' has type `set.set(lalr.item)',
>   expected type was `tree234.tree234(lalr.item, set.set(grammar.terminal))'.
> /home/pwa/Work/gws_shorter_errors/extras/moose/lalr.m:538: In clause for
>   predicate `propagate3'/7:
>   in argument 1 of call to predicate `map.init'/1:
>   type error:
>   variable `X1' has type `set.set(lalr.item)',
>   expected type was `tree234.tree234(V_V_1, V_V_2)'.
> 
> 
> Currently this change would only kick in when the context is "too long".
> However, one unexpected benefit is that in vim the :cn, :cp commands will
> skip directly from one error to the next without going through the
> intermediate lines, so maybe the new format should be used even for short
> contexts?  On the other hand, the existing format is probably more readable
> when the context is short.
> 
> I'd rather not add another option to choose.
> 

I use the tool 'error' which takes the error output of mmc or some other
compiler and adds the errors as source code comments to the relevant parts of
my source files.  This will break with the new format, as in the example above
only the text "In clause for" would be added to my source file.

I think that to satisfy everyone (because people have different preferences and
workflows) we may need to introduce a new (set of) options to format errors
differently.

For example when using 'error' it would be best to have error messages similar
to the first example above except with long lines - the file and line number
should not be included in the 80 column limit.  This is because error strips
off the context information before placing the error in the source file.

On another topic, what source code formatting conventions does Mission Critical
use for it's Mercury files.  Is there a policy or simply a defacto-standard?

Thanks.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.mercurylang.org/archives/developers/attachments/20090515/8554b615/attachment.sig>