[plt-dev] syntax-case error messages

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 macros, like the class system, I observe
pain staking attention to giving good error messages as if it is the
job of the macro not the macro matching system, etc.

Perhaps these syntax tests in class% have the same relation to
hypothetical syntax contracts that the low-level type tests have to
proper contracts. Except that since syntax contracts don't exist, we
don't see them.

My opinion is simply that good macros should have good errors and they
are buggy if they don't. If they get those good errors through an
elegant syntax contract system, great. If they have to get them in a
grosser way, too bad for them, but good for me. Just like functions
should have good error messages and if it is a simple provide/contract
that gives them, great.

Maybe I'm not arguing with Matthias. Maybe I am arguing with Jon. Jon
should not have said, "This macro application gives a bad error
message. Syntax-case: Grr!" He should have said, "This macro
application gives a bad error message. Macro: Grrr!"

Jay

On Mon, Mar 29, 2010 at 4:58 PM, 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
>>>
>
>



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