Robby Findler wrote:
On Mon, Mar 29, 2010 at 6:33 PM, Matthias Felleisen
<[email protected]> 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
_________________________________________________
For list-related administrative tasks:
http://list.cs.brown.edu/mailman/listinfo/plt-dev
