[plt-dev] syntax-case error messages

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 quickly than willfully hiding information
> from the developer.
> 
> Robby
> 
> On Monday, March 29, 2010, Matthias Felleisen <matthias at ccs.neu.edu> 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 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
>>>> 
>> 
>>