Re: [racket-dev] guidelines on error messages -- please send feedback
Somewhat offtopic but could the *SL languages use levenshtien distances to find symbolically related variables? clang (a c++ compiler) does this and I find it immensely useful. foodar(); Error: `foodar' not found, did you mean 'foobar' ? On 06/03/2011 11:21 AM, Shriram Krishnamurthi wrote: Guillaume, Kathi and I have created a set of guidelines for writing error messages for *SL. For consistency, these guidelines need to be used also by authors of libraries including Teachpacks, etc. These guidelines are currently being applied to all the error messages in *SL in the core distribution. Please review these guidelines and let us know if anything is unclear. We'd like to hear back from you within a week, by Fri, June 10 We have had to compromise on the description a little to make everything fit into a small number of pages, which we did because we really do hope people will print these out and put them on the wall or next to their monitor to refer to while writing code. Therefore, lengthy descriptions are out. In particular, rationale is also out. If you are curious about the rationales for any of these things, please do ask. After this is settled next week, we will send this to users@ and also to edu@ to tell instructors to follow these terms. Thanks, Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] guidelines on error messages -- please send feedback
An hour and a half ago, Shriram Krishnamurthi wrote: Please review these guidelines and let us know if anything is unclear. We'd like to hear back from you within a week, by * Start the message with the name of the construct whose constraint is being violated, followed by a colon. Should give a quick example to clarify that `error' does that when given a symbol. I can see people following this blindly and getting - (error 'foo foo: blah blah) foo: foo: blah blah * ... somewhat anthropomorphically ... See second item in the guidelines, apply reflection. * procedure, primitive name, primitive operator, predicate, selector, constructor - function +1, for more than the student languages. * variable - identifier (-0.52 because I can see it leaking out of the SLs) * do not write `' around keyword This can work only in a limited context, where you use colors/font/etc or you know that there is no keyword in your world that can be confused with text like `like'. Perhaps it would be a hook to start using some unicode things? 〈x〉 «x» ⌈x⌋ -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] guidelines on error messages -- please send feedback
I think that falls under the don't make suggestions heading. For the full Racket language, that would be fine -- like you say, you as a professional computer scientist find it useful. But for novice programmers, if they didn't in fact mean foobar they may fix it to be foobar instead, and assume that must be correct because DrRacket said so. Carl Eastlund On Fri, Jun 3, 2011 at 3:12 PM, Jon Rafkind rafk...@cs.utah.edu wrote: Somewhat offtopic but could the *SL languages use levenshtien distances to find symbolically related variables? clang (a c++ compiler) does this and I find it immensely useful. foodar(); Error: `foodar' not found, did you mean 'foobar' ? On 06/03/2011 11:21 AM, Shriram Krishnamurthi wrote: Guillaume, Kathi and I have created a set of guidelines for writing error messages for *SL. For consistency, these guidelines need to be used also by authors of libraries including Teachpacks, etc. These guidelines are currently being applied to all the error messages in *SL in the core distribution. Please review these guidelines and let us know if anything is unclear. We'd like to hear back from you within a week, by Fri, June 10 We have had to compromise on the description a little to make everything fit into a small number of pages, which we did because we really do hope people will print these out and put them on the wall or next to their monitor to refer to while writing code. Therefore, lengthy descriptions are out. In particular, rationale is also out. If you are curious about the rationales for any of these things, please do ask. After this is settled next week, we will send this to users@ and also to edu@ to tell instructors to follow these terms. Thanks, Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] guidelines on error messages -- please send feedback
Thanks for this document. For my own teachpacks, I tried to make the error messages consistent by creating all error messages in one file (htdp/error). But you're also reducing their complexity and this is even more important. The key is that students must understand the problem. A couple of comments: 1. We need to create a glossary for all terms used in error message and link them to the teaching languages. 2. You rule out some words that are consistently used in HtDP. I don't doubt that you have a rationale based on studies of students and I not interested in bringing these words back. But teachers may use them, and students may read them. Constructor and selector and predicate come to mind. So: 1a. We may wish to supplement the entries with synonyms that connect the words to equivalent words in HtDP. 3. The guidelines should go into the docs as a scribble document. We should supplement them with a document on how to write teachpack. For now, this document could just point forward to your document. They should also be linked to from a file in the lang/ documentation. Let me know when it's settled. I'd be happy to edit the draft documents and I'll tackle the teachpack error messages then. -- Matthias On Jun 3, 2011, at 1:21 PM, Shriram Krishnamurthi wrote: Guillaume, Kathi and I have created a set of guidelines for writing error messages for *SL. For consistency, these guidelines need to be used also by authors of libraries including Teachpacks, etc. These guidelines are currently being applied to all the error messages in *SL in the core distribution. Please review these guidelines and let us know if anything is unclear. We'd like to hear back from you within a week, by Fri, June 10 We have had to compromise on the description a little to make everything fit into a small number of pages, which we did because we really do hope people will print these out and put them on the wall or next to their monitor to refer to while writing code. Therefore, lengthy descriptions are out. In particular, rationale is also out. If you are curious about the rationales for any of these things, please do ask. After this is settled next week, we will send this to users@ and also to edu@ to tell instructors to follow these terms. Thanks, Shriram error message composition guidelines.pdf_ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] guidelines on error messages -- please send feedback
On Jun 3, 2011, at 3:13 PM, Jay McCarthy wrote: Use ‘argument’ for actual arguments and ‘variable’ for formal arguments and in the body of the definition. I prefer argument and parameter name, because until ASL, they don't vary. But it seems you prefer just variable, because you don't want two terms for the things made by 'define' and the things made by 'lambda'? This is very bikesheddy, but I dislike your choice. I agree with Jay here. I explicitly address the distinction between argument and parameter (i.e. formal argument) in _Picturing Programs_; to me, variable (in *SL) means the identifier in (define identifier expr), and its subsequent occurrences. Stephen Bloch sbl...@adelphi.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] guidelines on error messages -- please send feedback
Kathi is understating it. There are TWO notions of variable. In algebra, in f(x) = x^2, x is called a variable because it varies across invocations of f -- which is different from the CS notion of varies within a single invocation. So it's not even illegitimate given the other meaning of variable. (As you know, I make a royal fuss about this in 173. So it took me a while to reconcile to this change. But I think it's absolutely right.) On Fri, Jun 3, 2011 at 3:52 PM, Kathi Fisler kfis...@cs.wpi.edu wrote: The choice of variable is motivated by students and the desire to align with terms they know from high school math. The distinction between variable and identifier is too subtle for many students. Kathi On Fri, Jun 3, 2011 at 3:13 PM, Jay McCarthy jay.mccar...@gmail.com wrote: Use ‘argument’ for actual arguments and ‘variable’ for formal arguments and in the body of the definition. I prefer argument and parameter name, because until ASL, they don't vary. But it seems you prefer just variable, because you don't want two terms for the things made by 'define' and the things made by 'lambda'? This is very bikesheddy, but I dislike your choice. Jay 2011/6/3 Shriram Krishnamurthi s...@cs.brown.edu: Guillaume, Kathi and I have created a set of guidelines for writing error messages for *SL. For consistency, these guidelines need to be used also by authors of libraries including Teachpacks, etc. These guidelines are currently being applied to all the error messages in *SL in the core distribution. Please review these guidelines and let us know if anything is unclear. We'd like to hear back from you within a week, by Fri, June 10 We have had to compromise on the description a little to make everything fit into a small number of pages, which we did because we really do hope people will print these out and put them on the wall or next to their monitor to refer to while writing code. Therefore, lengthy descriptions are out. In particular, rationale is also out. If you are curious about the rationales for any of these things, please do ask. After this is settled next week, we will send this to users@ and also to edu@ to tell instructors to follow these terms. Thanks, Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] guidelines on error messages -- please send feedback
Where there is subtyping, same and different are not so clear. set-foo-bar!, foo-bar, and foo? are all different things at the level of mutator, selector, and predicate, but they are the same thing one level of abstraction up, where they are all functions or operators. So we are not advocating lying; we're simply saying don't make more distinctions than necessary. The problem we're seeing is that, because students don't know these additional words, they are not getting *more* information, they are getting *significantly less*: they're being told in the errors about gidgets and whosies and whatchamacallits. Shriram On Fri, Jun 3, 2011 at 8:05 PM, Jay McCarthy jay.mccar...@gmail.com wrote: Guillaume's homework is that students get confused with all the names for the same things. IMHO, if there are different things, then they should have different names. The students could still confuse the things, and that would be bad for our classes. DrRacket calling the different things the same thing would, IMHO, make it easier for students to confuse the concepts, and that's worse. Jay 2011/6/3 Matthias Felleisen matth...@ccs.neu.edu: HtDP uses (define variable expression) (define (function-name parameter ...) function-body) --- function header --- (lambda (parameter ...) ... variable ...) but it also says that globally defined variables are constants until we hit ASL. Because then they aren't. ;; --- I think we should start with the reduced set of words that Guillaume et al have come up with and if we notice problems we should expand the vocabulary or revise it carefully. None of us has research to back up our opinions. At least Guillaume et al have done some homework here. We need to acknowledge this. On Jun 3, 2011, at 7:52 PM, Stephen Bloch wrote: On Jun 3, 2011, at 3:13 PM, Jay McCarthy wrote: Use ‘argument’ for actual arguments and ‘variable’ for formal arguments and in the body of the definition. I prefer argument and parameter name, because until ASL, they don't vary. But it seems you prefer just variable, because you don't want two terms for the things made by 'define' and the things made by 'lambda'? This is very bikesheddy, but I dislike your choice. I agree with Jay here. I explicitly address the distinction between argument and parameter (i.e. formal argument) in _Picturing Programs_; to me, variable (in *SL) means the identifier in (define identifier expr), and its subsequent occurrences. Stephen Bloch sbl...@adelphi.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] guidelines on error messages -- please send feedback
* Start the message with the name of the construct whose constraint is being violated, followed by a colon. Should give a quick example to clarify that `error' does that when given a symbol. I can see people following this blindly and getting - (error 'foo foo: blah blah) foo: foo: blah blah AGREED: GM, add to the todo list. (Though the persistence of such an error would also suggest that the message author never ran DrRacket!) * ... somewhat anthropomorphically ... See second item in the guidelines, apply reflection. Are you referring to the concise and clear bullet? Can you make your point less obliquely? * variable - identifier (-0.52 because I can see it leaking out of the SLs) Do you mean identifier - variable? At any rate, we're pretty set on this one, perhaps more so than just about any other edit. * do not write `' around keyword This can work only in a limited context, where you use colors/font/etc or you know that there is no keyword in your world that can be confused with text like `like'. Perhaps it would be a hook to start using some unicode things? x «x » ?x? Perhaps, but the ... notation is actually confusing. We have some evidence for this. So, while we're open to ideas, we think the current notation is not quite working. Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] guidelines on error messages -- please send feedback
Oh, I'm all in favor of skipping identifier. But using the word variable both for global variables (i.e. constants) and for function parameters strikes me as asking for confusion. They're introduced by different syntax, they get their values in different ways, they have different scopes, etc. On Jun 3, 2011, at 8:14 PM, Shriram Krishnamurthi wrote: Kathi is understating it. There are TWO notions of variable. In algebra, in f(x) = x^2, x is called a variable because it varies across invocations of f Is the x in f(x) indeed consistently called a variable in high school math classes? Or do they also use words like parameter or argument? Stephen Bloch sbl...@adelphi.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] guidelines on error messages -- please send feedback
Oh, I'm all in favor of skipping identifier. But using the word variable both for global variables (i.e. constants) and for function parameters strikes me as asking for confusion. Okay. We have no evidence one way or the other. It could be something we try to investigate. Given our observation (for other terms) that fine-grained distinctions actually cause more confusion than help, I am not at all ready to buy your argument. Moreover, I have also come to distrust arguments from pure reason in this area. Is the x in f(x) indeed consistently called a variable in high school math classes? Or do they also use words like parameter or argument? There is no consistency across books. We do know that many math books and educators use variable. In addition, we have not run into either Bootstrap or college students who had trouble with the term variable. It's also a term I hear from people who studied in other countries (so is parameter, but much less so argument). That's why we chose it. Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] guidelines on error messages -- please send feedback
I have the same latent feelings as Stephen, but Shriram's argument has convinced me enough to put them away until I see a problem in practice. Jay 2011/6/3 Stephen Bloch sbl...@adelphi.edu: On Jun 3, 2011, at 8:34 PM, Shriram Krishnamurthi wrote: Oh, I'm all in favor of skipping identifier. But using the word variable both for global variables (i.e. constants) and for function parameters strikes me as asking for confusion. Okay. We have no evidence one way or the other. It could be something we try to investigate. Given our observation (for other terms) that fine-grained distinctions actually cause more confusion than help, I am not at all ready to buy your argument. Moreover, I have also come to distrust arguments from pure reason in this area. Fair enough. Data are good. But it seems to me that the difference (to a novice) between (a) something that's given a value once and for all where its name is defined, and (b) something that's a place-holder that takes on a different value every time a particular function is called is anything BUT a fine distinction. Stephen Bloch sbl...@adelphi.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] guidelines on error messages -- please send feedback
I agree that simplifying the error messages is a good idea and will be extremely helpful, but is there a good reason not to *teach* students the students much of this vocabulary? Many (most?) high school science textbooks have a Vocabulary section at the end of each section/chapter that defines the important terminology for that section, and it is common test students on the vocabulary via tests or quizzes. I have toyed with the idea of giving my students a weekly vocabulary list to study that would not only include formal technical items but also the informal vocabulary that computer scientists all the time (e.g. call, passing, invoke, etc. I think it would be reasonable to give students a set of procedure definitions and ask them to circle the variables, underline the parameters, identify function calls, etc. We use this terminology all the time in our lectures and notes; it seems unfair not to explain to the students what all the words mean. Justin On Fri, Jun 3, 2011 at 8:34 PM, Shriram Krishnamurthi s...@cs.brown.edu wrote: Oh, I'm all in favor of skipping identifier. But using the word variable both for global variables (i.e. constants) and for function parameters strikes me as asking for confusion. Okay. We have no evidence one way or the other. It could be something we try to investigate. Given our observation (for other terms) that fine-grained distinctions actually cause more confusion than help, I am not at all ready to buy your argument. Moreover, I have also come to distrust arguments from pure reason in this area. Is the x in f(x) indeed consistently called a variable in high school math classes? Or do they also use words like parameter or argument? There is no consistency across books. We do know that many math books and educators use variable. In addition, we have not run into either Bootstrap or college students who had trouble with the term variable. It's also a term I hear from people who studied in other countries (so is parameter, but much less so argument). That's why we chose it. Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] guidelines on error messages -- please send feedback
The choice of variable is motivated by students and the desire to align with terms they know from high school math. The distinction between variable and identifier is too subtle for many students. Kathi On Fri, Jun 3, 2011 at 3:13 PM, Jay McCarthy jay.mccar...@gmail.com wrote: Use ‘argument’ for actual arguments and ‘variable’ for formal arguments and in the body of the definition. I prefer argument and parameter name, because until ASL, they don't vary. But it seems you prefer just variable, because you don't want two terms for the things made by 'define' and the things made by 'lambda'? This is very bikesheddy, but I dislike your choice. Jay 2011/6/3 Shriram Krishnamurthi s...@cs.brown.edu: Guillaume, Kathi and I have created a set of guidelines for writing error messages for *SL. For consistency, these guidelines need to be used also by authors of libraries including Teachpacks, etc. These guidelines are currently being applied to all the error messages in *SL in the core distribution. Please review these guidelines and let us know if anything is unclear. We'd like to hear back from you within a week, by Fri, June 10 We have had to compromise on the description a little to make everything fit into a small number of pages, which we did because we really do hope people will print these out and put them on the wall or next to their monitor to refer to while writing code. Therefore, lengthy descriptions are out. In particular, rationale is also out. If you are curious about the rationales for any of these things, please do ask. After this is settled next week, we will send this to users@ and also to edu@ to tell instructors to follow these terms. Thanks, Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
