[plt-dev] syntax-case error messages

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
>>>
>
>