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 <matth...@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 <matth...@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 >>> <matth...@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 <j...@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 >>> > > _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev