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 <[email protected]> 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 <[email protected]> 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 >>>> <[email protected]> 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 <[email protected]> >>>> 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
