Re: [racket-dev] very unhelpful beginner language error message, possible fix proposed
I don't understand how to go back to normal mode now? _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] very unhelpful beginner language error message, possible fix proposed
On Feb 13, 2012, at 7:44 PM, David Van Horn wrote: On 2/13/12 7:32 PM, Stephen Bloch wrote: In ISL, there's an additional case: a local variable might or might not be bound to a function. That's a little more hassle to check, but it should be doable at compile-time. Again, if the first element of a cond-clause is an identifier bound to a function, trigger our clever error message at compile-time. Once you go to ISL you cannot tell whether a name refers to a function or a non-function without running code. You can't tell IN GENERAL, but in many cases you can. I'm suggesting that those cases cover the most common instances of this user error, so it would be worth checking for them. Stephen Bloch sbl...@adelphi.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] very unhelpful beginner language error message, possible fix proposed
On 2/13/12 7:32 PM, Stephen Bloch wrote: In ISL, there's an additional case: a local variable might or might not be bound to a function. That's a little more hassle to check, but it should be doable at compile-time. Again, if the first element of a cond-clause is an identifier bound to a function, trigger our clever error message at compile-time. Once you go to ISL you cannot tell whether a name refers to a function or a non-function without running code. ISL is higher-order; it just doesn't have lambda or the ability to compute functions in operator position. Even that's a lie if you're willing to squint a little. David _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] very unhelpful beginner language error message, possible fix proposed
On Feb 13, 2012, at 5:07 PM, David Van Horn wrote: > On 2/13/12 4:20 PM, Stephen Bloch wrote: >> >> On Feb 13, 2012, at 8:28 AM, David Van Horn wrote: >> >>> In BSL, you can detect when the first element of a clause is a variable >>> bound to a function, but I don't follow the reasoning about ISL. You can't >>> distinguish good from bad uses without running the code because you can't >>> tell if a name refers to a function or a non-function. >> >> Not reliably, because the student COULD be using a parameter or a local >> variable in that position. But in the COMMON case of this error, the >> student will use a predefined function or an explicitly user-defined >> top-level function, and it should be possible to recognize those at >> syntax-check-time. > > But even if the name is a parameter, it cannot be bound to a function. If > it's a local, it either is or isn't a function -- you can tell from the > definition. In ISLL, a parameter could be bound to a function. You're right, in ISL it can't, so that's even easier. > I think it's correct to consider this a syntax error, not a run-time error. > It should just have a better message. > >> Which leaves >> >>> cond: question result is not true or false: (lambda (a1) ...) >> >> as a good error message to report at run time in the rare cases that don't >> match the above description. > > Except you don't want to say lambda in BSL. No, of course not. So to sum it up: In BSL and BSLL, you can tell at compile-time what identifiers are bound to functions (either predefined or user-defined-at-the-top-level). If the first element of a cond-clause is such an identifier, trigger our clever-error-message-to-be-determined. In ISL, there's an additional case: a local variable might or might not be bound to a function. That's a little more hassle to check, but it should be doable at compile-time. Again, if the first element of a cond-clause is an identifier bound to a function, trigger our clever error message at compile-time. In ISLL, there's another additional case: a parameter, for which you REALLY can't tell (without a bunch of heavy-duty type inference, and in general it's probably undecidable) whether it's bound to a function. In that case, you can use the aforementioned run-time error message involving lambda. In all the previous cases, which we should still be able to detect and which should cover the great majority of cases, trigger the clever compile-time error message. In ASL and #lang racket, there are still cases in which you could trigger this error message. There's already a mechanism to tell whether a particular variable is ever mutated in a particular module (I don't remember what this is used for, but people have mentioned adding a "set!" as a work-around to various provide/require problems), so if the cond-clause-entry in question is an identifier that isn't mutated in this module and is bound to a function, trigger the clever error message. Although for ASL and #lang racket, the clever error message isn't as important Stephen Bloch sbl...@adelphi.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] very unhelpful beginner language error message, possible fix proposed
On Feb 13, 2012, at 8:28 AM, David Van Horn wrote: > In BSL, you can detect when the first element of a clause is a variable bound > to a function, but I don't follow the reasoning about ISL. You can't > distinguish good from bad uses without running the code because you can't > tell if a name refers to a function or a non-function. Not reliably, because the student COULD be using a parameter or a local variable in that position. But in the COMMON case of this error, the student will use a predefined function or an explicitly user-defined top-level function, and it should be possible to recognize those at syntax-check-time. Which leaves > cond: question result is not true or false: (lambda (a1) ...) as a good error message to report at run time in the rare cases that don't match the above description. Stephen Bloch sbl...@adelphi.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] very unhelpful beginner language error message, possible fix proposed
On 2/13/12 4:20 PM, Stephen Bloch wrote: On Feb 13, 2012, at 8:28 AM, David Van Horn wrote: In BSL, you can detect when the first element of a clause is a variable bound to a function, but I don't follow the reasoning about ISL. You can't distinguish good from bad uses without running the code because you can't tell if a name refers to a function or a non-function. Not reliably, because the student COULD be using a parameter or a local variable in that position. But in the COMMON case of this error, the student will use a predefined function or an explicitly user-defined top-level function, and it should be possible to recognize those at syntax-check-time. But even if the name is a parameter, it cannot be bound to a function. If it's a local, it either is or isn't a function -- you can tell from the definition. I think it's correct to consider this a syntax error, not a run-time error. It should just have a better message. Which leaves cond: question result is not true or false: (lambda (a1) ...) as a good error message to report at run time in the rare cases that don't match the above description. Except you don't want to say lambda in BSL. David _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] very unhelpful beginner language error message, possible fix proposed
On 2/13/12 8:11 AM, Stephen Bloch wrote: On Feb 13, 2012, at 5:05 AM, Marijn wrote: ... it highlighted the id "list-sum-odd" in what should have been the 'else' case, and wrote: "list-sum-odd: expected a function call, but there is no open parenthesis before this function" ... which is really terrible, because there *IS* a parenthesis right before the function name. How about changing the message such that it complains about a shortage of parentheses without stating that there are none? - - expected a function call, but there is an open parenthesis missing before this function name Doesn't help much: as any student can see, there IS an open parenthesis before this function name. Or maybe formulate it in a positive way to encourage the user to insert parentheses? - - expected a function call, but found a function name; to call it add surrounding parentheses It's GOT surrounding parentheses. The mistake the student made was at the "cond" level, not at the level of this function call, so the "right" error message has to say something about "cond", like -- cond: each clause must be a question/answer pair enclosed in brackets. You have two expressions that look like the "question" and the "answer", but you need another pair of brackets around the two of them. It should be possible for the "cond" macro to detect this situation, at least in BSL, because the first element of what should be a cond-clause is a function name, and that's not a complete expression. In ISLL, a function name can appear as an expression in its own right, but it still doesn't make sense as the first element of a cond-clause because a function name isn't a boolean: if it's defined, then it's non-null and therefore true, and if it's not, the student shouldn't be mentioning it at all. Not until ASL does it become possible (albeit unlikely) that a function name could make sense as a condition. In BSL, you can detect when the first element of a clause is a variable bound to a function, but I don't follow the reasoning about ISL. You can't distinguish good from bad uses without running the code because you can't tell if a name refers to a function or a non-function. ISL actually gives the best error message in my opinion: cond: question result is not true or false: (lambda (a1) ...) But it only does this at run time (as it must). The syntax error for BSL could be similar though: cond: question is not an expression but a function name: list-sum-odd David _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] very unhelpful beginner language error message, possible fix proposed
On Feb 13, 2012, at 5:05 AM, Marijn wrote: >> ... it highlighted the id "list-sum-odd" in what should have >> been the 'else' case, and wrote: >> >> "list-sum-odd: expected a function call, but there is no open >> parenthesis before this function" >> >> ... which is really terrible, because there *IS* a parenthesis >> right before the function name. > > How about changing the message such that it complains about a shortage > of parentheses without stating that there are none? > > - - expected a function call, but there is an open parenthesis missing > before this function name Doesn't help much: as any student can see, there IS an open parenthesis before this function name. > Or maybe formulate it in a positive way to encourage the user to > insert parentheses? > > - - expected a function call, but found a function name; to call it add > surrounding parentheses It's GOT surrounding parentheses. The mistake the student made was at the "cond" level, not at the level of this function call, so the "right" error message has to say something about "cond", like -- cond: each clause must be a question/answer pair enclosed in brackets. You have two expressions that look like the "question" and the "answer", but you need another pair of brackets around the two of them. It should be possible for the "cond" macro to detect this situation, at least in BSL, because the first element of what should be a cond-clause is a function name, and that's not a complete expression. In ISLL, a function name can appear as an expression in its own right, but it still doesn't make sense as the first element of a cond-clause because a function name isn't a boolean: if it's defined, then it's non-null and therefore true, and if it's not, the student shouldn't be mentioning it at all. Not until ASL does it become possible (albeit unlikely) that a function name could make sense as a condition. Stephen Bloch sbl...@adelphi.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] very unhelpful beginner language error message, possible fix proposed
+1 Robby On Fri, Feb 10, 2012 at 4:52 PM, Matthias Felleisen wrote: > > > Yes, and it was submitted in some form as a bug before. Why don't you modify > teach.rkt and see whether you like the result better. Then submit. > > > > > On Feb 10, 2012, at 5:43 PM, Danny Yoo wrote: > >>> >>> "Ho Ho!" thought I. "Beginner Student Racket will give a much better error >>> message." Actually, though, the error message was much worse: it >>> highlighted the id "list-sum-odd" in what should have been the 'else' case, >>> and wrote: >>> >>> "list-sum-odd: expected a function call, but there is no open parenthesis >>> before this function" >>> >>> ... which is really terrible, because there *IS* a parenthesis right before >>> the function name. >> >> >> This is a variation of one of the cases described in Guillaume's paper >> on error messages. Figure 4 of >> http://gmarceau.qc.ca/papers/Marceau-2010-Measuring-Effectiveness.pdf >> _ >> Racket Developers list: >> http://lists.racket-lang.org/dev > > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] very unhelpful beginner language error message, possible fix proposed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10-02-12 23:38, John Clements wrote: > A user on stackoverflow had a question about this code: > > (define list-sum-odd (lambda (list) (cond ((null? list) 0) ((odd? > (car list)) (+ (car list) (list-sum-odd (cdr list (list-sum-odd > (cdr list) > > > (list-sum-odd '(3 4 5)) > > ... which signalled an error. In #lang racket, you get > > "+: expects type as 2nd argument, given: '(5); other > arguments were: 3" > > ... which is the right error for #lang racket. The response showed > him that he'd forgotten the "else" in his last clause. > > "Ho Ho!" thought I. "Beginner Student Racket will give a much > better error message." Actually, though, the error message was much > worse: it highlighted the id "list-sum-odd" in what should have > been the 'else' case, and wrote: > > "list-sum-odd: expected a function call, but there is no open > parenthesis before this function" > > ... which is really terrible, because there *IS* a parenthesis > right before the function name. How about changing the message such that it complains about a shortage of parentheses without stating that there are none? - - expected a function call, but there is an open parenthesis missing before this function name Or maybe formulate it in a positive way to encourage the user to insert parentheses? - - expected a function call, but found a function name; to call it add surrounding parentheses Marijn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEARECAAYFAk844HoACgkQp/VmCx0OL2yVKACXWLUXrftUvkaqxqMkmK0LY/UO OwCgmulM/kFmLsxoQfv4t+flPv9D4G8= =/Yj0 -END PGP SIGNATURE- _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] very unhelpful beginner language error message, possible fix proposed
>> This is a variation of one of the cases described in Guillaume's paper >> on error messages. Figure 4 of >> http://gmarceau.qc.ca/papers/Marceau-2010-Measuring-Effectiveness.pdf > > Yes, I agree. Are you suggesting that there's low-hanging fruit in the form > of a more general solution? I'm hoping that your bug fix applies to both 'and' as well as primitive functions. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] very unhelpful beginner language error message, possible fix proposed
On Feb 10, 2012, at 2:43 PM, Danny Yoo wrote: >> >> "Ho Ho!" thought I. "Beginner Student Racket will give a much better error >> message." Actually, though, the error message was much worse: it highlighted >> the id "list-sum-odd" in what should have been the 'else' case, and wrote: >> >> "list-sum-odd: expected a function call, but there is no open parenthesis >> before this function" >> >> ... which is really terrible, because there *IS* a parenthesis right before >> the function name. > > > This is a variation of one of the cases described in Guillaume's paper > on error messages. Figure 4 of > http://gmarceau.qc.ca/papers/Marceau-2010-Measuring-Effectiveness.pdf Yes, I agree. Are you suggesting that there's low-hanging fruit in the form of a more general solution? John smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] very unhelpful beginner language error message, possible fix proposed
Yes, and it was submitted in some form as a bug before. Why don't you modify teach.rkt and see whether you like the result better. Then submit. On Feb 10, 2012, at 5:43 PM, Danny Yoo wrote: >> >> "Ho Ho!" thought I. "Beginner Student Racket will give a much better error >> message." Actually, though, the error message was much worse: it highlighted >> the id "list-sum-odd" in what should have been the 'else' case, and wrote: >> >> "list-sum-odd: expected a function call, but there is no open parenthesis >> before this function" >> >> ... which is really terrible, because there *IS* a parenthesis right before >> the function name. > > > This is a variation of one of the cases described in Guillaume's paper > on error messages. Figure 4 of > http://gmarceau.qc.ca/papers/Marceau-2010-Measuring-Effectiveness.pdf > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] very unhelpful beginner language error message, possible fix proposed
> > "Ho Ho!" thought I. "Beginner Student Racket will give a much better error > message." Actually, though, the error message was much worse: it highlighted > the id "list-sum-odd" in what should have been the 'else' case, and wrote: > > "list-sum-odd: expected a function call, but there is no open parenthesis > before this function" > > ... which is really terrible, because there *IS* a parenthesis right before > the function name. This is a variation of one of the cases described in Guillaume's paper on error messages. Figure 4 of http://gmarceau.qc.ca/papers/Marceau-2010-Measuring-Effectiveness.pdf _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] very unhelpful beginner language error message, possible fix proposed
A user on stackoverflow had a question about this code: (define list-sum-odd (lambda (list) (cond ((null? list) 0) ((odd? (car list)) (+ (car list) (list-sum-odd (cdr list (list-sum-odd (cdr list) (list-sum-odd '(3 4 5)) ... which signalled an error. In #lang racket, you get "+: expects type as 2nd argument, given: '(5); other arguments were: 3" ... which is the right error for #lang racket. The response showed him that he'd forgotten the "else" in his last clause. "Ho Ho!" thought I. "Beginner Student Racket will give a much better error message." Actually, though, the error message was much worse: it highlighted the id "list-sum-odd" in what should have been the 'else' case, and wrote: "list-sum-odd: expected a function call, but there is no open parenthesis before this function" ... which is really terrible, because there *IS* a parenthesis right before the function name. I can see perfectly clearly how this arises as the composition of macros; would it make sense for the 'cond' macro to check to see whether its test expression is a bare function name before rearranging the pieces and continuing with expansion? Specifically, it looks like such a check could be inserted on line 1316 of teach.rkt, in this code: [(question answer) (with-syntax ([verified (stepper-ignore-checker (syntax (verify-boolean question 'cond)))]) (syntax/loc clause (verified answer)))] ... where you could issue an error message for questions that are ids that are bound to user-defined functions--we have this information, right? John smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev