I'll fix the docs. (The error message is based on the syntax object
given to `syntax-case', not a macro-invocation context.)
At Tue, 30 Mar 2010 07:40:12 -0600, Robby Findler wrote:
> The docs for syntax-case say "If no clause matches, then the
> exn:fail:syntax exception is raised." Okay I change
The docs for syntax-case say "If no clause matches, then the
exn:fail:syntax exception is raised." Okay I change this to "If no
clause matches, then the exn:fail:syntax exception is raised with a
generic error message indicating a syntax error in the most recently
invoked macro (via the @scheme[#f]
But the majority in that file are definitely of the pattern!
Robby
On Tue, Mar 30, 2010 at 7:17 AM, Robby Findler
wrote:
> On Mon, Mar 29, 2010 at 8:48 PM, Sam Tobin-Hochstadt
> wrote:
>> On Mon, Mar 29, 2010 at 10:36 PM, Robby Findler
>> wrote:
>>>
>>> This hypothesis is testable, right? We
On Mon, Mar 29, 2010 at 8:48 PM, Sam Tobin-Hochstadt wrote:
> On Mon, Mar 29, 2010 at 10:36 PM, Robby Findler
> wrote:
>>
>> 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 messa
On Mar 30, 2010, at 7:45 AM, Ryan Culpepper wrote:
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 h
On Mon, Mar 29, 2010 at 6:33 PM, Matthias Felleisen
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-
define-syntax-rule would be trivial to generate the right error
message since there can only be one case.
Jay
On Mon, Mar 29, 2010 at 8:48 PM, Sam Tobin-Hochstadt wrote:
> On Mon, Mar 29, 2010 at 10:36 PM, Robby Findler
> wrote:
>>
>> This hypothesis is testable, right? We can find all of the u
Robby Findler wrote:
On Mon, Mar 29, 2010 at 6:33 PM, Matthias Felleisen
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
On Mon, Mar 29, 2010 at 10:36 PM, Robby Findler
wrote:
>
> 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?
Note that every use of `sy
On Mon, Mar 29, 2010 at 6:33 PM, Matthias Felleisen
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-
I think my message (as in this one) was to cryptic. Try the one on syntax.
On Mar 29, 2010, at 9:35 PM, Robby Findler wrote:
> When you don't know how to specify WHAT (and we don't) then HOW is
> better than pretending we have a WHAT -- it helps people understand
> what has gone wrong more qui
But Matthew, that is not the choice! The choice is between a car of
null error and the "f or something that called it or something that it
called" failed error. There is no spec so there is no blame!
Robby
On Monday, March 29, 2010, Matthew Flatt wrote:
> At Mon, 29 Mar 2010 18:58:34 -0400, Mat
When you don't know how to specify WHAT (and we don't) then HOW is
better than pretending we have a WHAT -- it helps people understand
what has gone wrong more quickly than willfully hiding information
from the developer.
Robby
On Monday, March 29, 2010, Matthias Felleisen wrote:
>
> On Mar 29,
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
At Mon, 29 Mar 2010 18:58:34 -0400, Matthias Felleisen wrote:
>
> On Mar 29, 2010, at 6:36 PM, Robby Findler wrote:
>
> > By thisine of reasoning a scheme imlementation that didn't have
> > contracts should change car-of-null error message to say "a function
> > had an error" which seems wrong to
I believe that you've thought about this more than me.
All I can say is that when I look at the C code for PLT and for low
level Scheme functions where contracts aren't available, there are
many assertions that recreate error messages like the contract system
gives.
Similarly, if I look at good m
On Mar 29, 2010, at 6:36 PM, Robby Findler wrote:
> By thisine of reasoning a scheme imlementation that didn't have
> contracts should change car-of-null error message to say "a function
> had an error" which seems wrong to me.
No it would be ideal if it said "function f had an error" instead
By thisine of reasoning a scheme imlementation that didn't have
contracts should change car-of-null error message to say "a function
had an error" which seems wrong to me.
I agree with Jay.
Robby
On Monday, March 29, 2010, Matthias Felleisen wrote:
>
> Yeap, Lispers love that they can manipulat
Yeap, Lispers love that they can manipulate everything
and complain that everything manipulates them.
I think we should accept these kind of value-errors
when we are working on our own code. When we pull in
someone else's code and this happens, we should complain
until he adds contracts to the m
If I call (f 5) and the error pops up:
car: expects argument of type ; given 5
I could say, "A mis-user of a function shouldn't need to know that the
function is implemented with 'car' or even with pattern matching."
I would say that f is a broken function because it doesn't translate
errors in
On Mar 29, 2010, at 4:39 PM, Matthew Flatt wrote:
For now, I'm opposed to either change. A mis-user of a syntactic form
shouldn't need to know that the form is implemented with `syntax-case'
or even with pattern matching.
Eugene Kohlbecker would whole-heartedly agree here. Let's not confuse
For the syntactically wrong uses of `syntax-case',
At Mon, 29 Mar 2010 14:06:55 -0600, Jon Rafkind wrote:
> > (syntax-case #'1 () 2)
> bad clause in: 2
> > (syntax-case #'1 () [2])
> bad clause in: (2)
the actual error message said "_":
_: bad clause in: 2
I've fixed that bug so that it says
On 03/29/2010 02:31 PM, Jon Rafkind wrote:
FWIW, syntax-parse does a pretty good job with these same examples
except for one case. Ryan, can you fix the 'bad syntax' error?
-> (syntax-parse #'1)
readline-input::199: syntax-parse: expected non-empty sequence of
clauses in: (syntax-parse (syntax
FWIW, syntax-parse does a pretty good job with these same examples
except for one case. Ryan, can you fix the 'bad syntax' error?
-> (syntax-parse #'1)
readline-input::199: syntax-parse: expected non-empty sequence of
clauses in: (syntax-parse (syntax 1))
-> (syntax-parse #'1 2)
readline-input
I think putting "syntax-case:" at the front of the error message is
the right thing (and that's a predictable thought, as I'm sure Matthew
is thinking right now since it means that macros that use syntax-case
to do their error checking will now have to do a better job). Maybe
the presence of Ryan's
Attached is a small patch for syntax-case that makes some error messages
slightly more pleasant (at least to me).
Old:
> (syntax-case #'1 ())
bad syntax in: 1
> (syntax-case #'1 () 2)
bad clause in: 2
> (syntax-case #'1 () [2])
bad clause in: (2)
> (syntax-case #'1 () [2 2])
bad syntax in: 1
Ne
26 matches
Mail list logo
