Re: [racket-users] Possible bug in SEwPR, Exercise 15.1

> On the other hand, it would be a real stress test. So if you’re up to > it, try to use the binding mechanism and post on the list how you’re > doing. — Matthias That's my plan as soon as I finish reading SEwPR. I'll let you know how it goes. Thanks a lot to you all for all the kind advice.

Re: [racket-users] Possible bug in SEwPR, Exercise 15.1

On the other hand, it would be a real stress test. So if you’re up to it, try to use the binding mechanism and post on the list how you’re doing. — Matthias > On Jun 2, 2016, at 7:49 AM, Robby Findler wrote: > > It is designed for lexical scope, yes. If you

Re: [racket-users] Possible bug in SEwPR, Exercise 15.1

It is designed for lexical scope, yes. If you have a language with it's own interesting, non-standard notion of scope, you will probably have to (and, indeed, want to) model it explicitly. Robby On Thu, Jun 2, 2016 at 5:59 AM, Leandro Facchinetti wrote: >> Woah, cool! >> >>

Re: [racket-users] Possible bug in SEwPR, Exercise 15.1

> Woah, cool! > > Since the book was written, we have added support for binding > specifications to Redex. It's documentation is still in the process of > being improved, but you might have some interest in checking it out > (it is the part after #:binding-forms). I read the documentation and

Re: [racket-users] Possible bug in SEwPR, Exercise 15.1

Woah, cool! Since the book was written, we have added support for binding specifications to Redex. It's documentation is still in the process of being improved, but you might have some interest in checking it out (it is the part after #:binding-forms). Bugs in substitution functions are the

Re: [racket-users] Possible bug in SEwPR, Exercise 15.1

Thanks for adding the entry to the errata. It was fun finding the bug in my version: I forgot to /unfreeze/ (call) the function that represents the branches of the `if' statement. I used DrRacket's visual tools—the stepper, the tracer and the debugger—to figure the issue. Not only that, but I

Re: [racket-users] Possible bug in SEwPR, Exercise 15.1

Thank you. I've pushed a fix. (The example upthread wasn't quite right; maybe fun to try to find the error by working thru the exercise? :) Robby On Wed, Jun 1, 2016 at 10:20 AM, Matthias Felleisen wrote: > > The fix will shortly appear here:

Re: [racket-users] Possible bug in SEwPR, Exercise 15.1

The fix will shortly appear here: http://redex.racket-lang.org/errata.html > On Jun 1, 2016, at 8:29 AM, lfacc...@jhu.edu wrote: > > Thanks for the blazing fast response and for clarifying it for me. Also, > thanks for acknowledgment; my name is Leandro Facchinetti. -- You received this

Re: [racket-users] Possible bug in SEwPR, Exercise 15.1

Thanks for the blazing fast response and for clarifying it for me. Also, thanks for acknowledgment; my name is Leandro Facchinetti. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from

Re: [racket-users] Possible bug in SEwPR, Exercise 15.1

> On Jun 1, 2016, at 7:22 AM, lfacc...@jhu.edu wrote: > > Hi, all, and authors of SEwPR in particular. > > I believe Exercise 15.1 has the following problems: > > 1. The function passed to the Y combinator should have an parameter > before `x' called `tri'. > > 2. `ifz' is not a construct

[racket-users] Possible bug in SEwPR, Exercise 15.1

Hi, all, and authors of SEwPR in particular. I believe Exercise 15.1 has the following problems: 1. The function passed to the Y combinator should have an parameter before `x' called `tri'. 2. `ifz' is not a construct in ISWIM as presented in the previous chapters. I could extend the