[plt-dev] syntax-case error messages

Robby Findler wrote:
> On Mon, Mar 29, 2010 at 6:33 PM, Matthias Felleisen 
> <matthias at ccs.neu.edu> wrote:
>> On Mar 29, 2010, at 7:18 PM, Jay McCarthy wrote:
>> 
>>> I believe that you've thought about this more than me.
>> I am not sure but I sure had a head-start on you. Plus it is my
>> distinct impression that everyone who starts with Lisp-y languages
>> goes through most of the learning process that the "Lisp community"
>> has gone through. (It's kind of like in biology.) For the purpose
>> of 'syntax discussions', I do count us all as Lispers.
>> 
>> So here we go. Syntax should be as dynamic as possible for the
>> implementor of language extensions and as static as possible for
>> users. That's especially true for the majority of programmers who
>> write no macros or only simplistic macros.
> 
> I think what you're saying here is that you want a gentle ramp where 
> you can go from simple macros that have bad error messages up to
> fancy ones that have good error messages. And I completely agree,
> iiuc.
> 
>> What does this mean? When the average programmer uses the language
>> and its syntactic libraries, there should be no distinction. When
>> something goes wrong with the syntax, report it in terms of the
>> 'what' of the syntax not in terms of how the macro failed. Just
>> imagine you'd get syntax error message from your Java compiler in
>> terms of the parsing technology used, not in terms of the grammar
>> parsed. You'd never ever touch the language again. I think this
>> applies to our syntax world too. That's what I mean with 'static'.
>> Then again, I have recanted on my belief that 'static syntax' means
>> no dynamics for the syntax implementor. I now do use three levels
>> of files to implement my syntactic extension (mostly world) so that
>> I do get single point of control and usable syntax for beginning
>> students.
> 
> Yes, I agree with this too: if the error messages are poor, you'll 
> stay away from the language.
> 
> But I don't see how this suggests that the error message "bad syntax"
>  is better than the error message "the syntax-case on line X didn't 
> have a matching case". To the naive programmer, they have equivalent 
> amounts of information (ie, nearly none). 

Really? I read the first as the macro saying "No, you got it wrong. Read 
the docs/source and figure it out." Not the most helpful error message, 
maybe, but since macro interfaces are so much more free-form than 
procedure interfaces, it's harder to say exactly what went wrong.

The other error message, on the other hand, has very much an internal 
error feel to it.

 > To the programmer that
> implemented the macro (or macros) in question, the latter one has a 
> lot more information and thus is preferable.

I do think it would be helpful to record more information and package it 
up with the syntax error. I imagine having an extra debug icon by syntax 
errors that I can click and see why the syntax was rejected. Kind of 
like how some Schemes let you enter the debugger on any error. But I 
don't think that level of information belongs in the error message.

> I think your argument goes along the lines that "usually when we get
> a 'bad syntax' error message, that message is actually accurate and
> the source location is pointing to the right place". And I think
> Matthew is also saying that and even going one step further to say
> that programmers are programming to the current syntax-case
> implementation and explicitly avoid writing the [else
> (raise-syntax-error #f "bad syntax" stx)] clause because they know
> that it is there.

I think that macro writers don't really think of 
syntax-rules/syntax-case as separate forms, at least when they're 
immediately inside of a define-syntax. They're just writing down the 
cases of the macro, and syntax-case is the container they have to put 
them. A macro expects syntax-case to reject syntax that doesn't fit any 
of the clauses *on the macro's behalf*. And I think macro writers will 
resent it if syntax-case starts worming its way into error messages.

On the other hand, for syntax-cases in auxiliary functions reporting the 
error in terms of the syntax being matched is often wrong and confusing. 
That's why syntax-parse has an optional #:context argument.

Ryan



> This hypothesis is testable, right? We can find all of the uses of 
> syntax-case that don't have a default clause and see if they actually
>  do have the right error message or if they get the wrong thing,
> right?
> 
>> (In the end it may all boil down to my POPL lecture: Errors
>> Matter.)
> 
> (Amen to that.)
> 
> Robby _________________________________________________ For
> list-related administrative tasks: 
> http://list.cs.brown.edu/mailman/listinfo/plt-dev