If you need a quick fix to get things going for your class, you might consider just doing things unsafely (with a few checks where you know they are needed). Don't use TR and then you don't get the contracts, and you can probably get the allocation down.
Robby On Sun, Nov 11, 2012 at 5:40 PM, John Clements <cleme...@brinckerhoff.org> wrote: > > On Nov 11, 2012, at 1:57 PM, Matthias Felleisen wrote: > >> >> On Nov 11, 2012, at 2:48 PM, John Clements wrote: >> >>>> >>>> I'm not sure why this would be. Is the code students write unrestricted? >>> >>> Pretty much, yes. So, for instance, a student might write: >>> >>> (signal-play >>> (network () >>> [s ((looper song2))] >>> [ctr ((loop-ctr 0 1))] >>> [on? (toggle ctr)] >>> [out (reverb s)])) >>> >>> where the signals take on float, boolean, or any kind of value. This >>> expands into something containing this "inner loop" procedure: >>> >>> (lambda () >>> (define s (n1)) >>> (define ctr (n2)) >>> (define on? (toggle ctr)) >>> (define out (reverb s)) >>> (set! saved-s s) >>> (set! saved-ctr ctr) >>> (set! saved-on? on?) >>> (set! saved-out out) >>> out) >>> >>> It would be pretty hard to assign types any tighter than "any" to these rhs >>> expressions. >> >> >> John, are the students really writing code w/o constraints? Would it be much >> of an imposition to ask for base types? > > I think it depends on the setup. In my case, I'm trying to add a reverb unit > for a class that's about 8 weeks into an 11-week semester. Retrofitting types > to the system would be bold at this point, even for me :). For next year? > maybe. I have to say that my experiences thus far with TR have taught me to > be a bit careful, though. I would want to experiment with such a setup before > deploying it. > > John > ____________________ Racket Users list: http://lists.racket-lang.org/users
