[plt-dev] syntax-case error messages

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 of "car of null mumbo jumbo". 


> I agree with Jay.


Then you're both wrong. 

You really want to report errors in terms of WHAT not HOW when possible. It's just true that HALTING doesn't allow this for good. Types (for the value level) are a good first approximation: they specify and we reject based on specification. Contracts are the next line of defense up, again on the level of values. 

Syntax isn't values. We know more already. 










> 
> Robby
> 
> On Monday, March 29, 2010, Matthias Felleisen <matthias at ccs.neu.edu> wrote:
>> 
>> 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 module.
>> 
>> The story for syntax looks analogous at first glance.
>> But we are missing syntax-contracts. So we write down
>> what we want the syntax extension to 'feel' like with
>> quasi grammars and whatever. We always do this, with
>> comments though. And therefore we should get errors
>> at the 'upper' level.
>> 
>> All in all, this is why I proposed the second half of
>> Ryan's dissertation as a thesis-level problem, and I
>> think we have mad progress.
>> 
>> 
>> 
>> 
>> 
>> On Mar 29, 2010, at 5:30 PM, Jay McCarthy wrote:
>> 
>> 
>> If I call (f 5) and the error pops up:
>> 
>> car: expects argument of type <pair>; 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 its implementation (not checking enough before calling car)
>> to errors in the user's input.
>> 
>> Similarly, I think that syntax-case errors should say 'syntax-case' in
>> them. If a macro lets such an error escape, then it is a bad macro,
>> just like f would be a bad function.
>> 
>> In practice this means that good syntax-case macros have a clause:
>> 
>> [_ (raise-syntax-error 'macro "My syntax is ...." stx)]
>> 
>> Jay
>> 
>> On Mon, Mar 29, 2010 at 2:43 PM, Matthias Felleisen
>> <matthias at ccs.neu.edu> wrote:
>> 
>> 
>> 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 how a
>> macro is implemented with what it supposed to
>> do._________________________________________________
>>  For list-related administrative tasks:
>>  http://list.cs.brown.edu/mailman/listinfo/plt-dev
>> 
>> 
>> 
>> 
>> 
>> --
>> Jay McCarthy <jay at cs.byu.edu>
>> Assistant Professor / Brigham Young University
>> http://teammccarthy.org/jay
>> 
>> "The glory of God is Intelligence" - D&C 93
>> 
>> 
>> _________________________________________________
>>  For list-related administrative tasks:
>>  http://list.cs.brown.edu/mailman/listinfo/plt-dev
>>