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
smime.p7s
Description: S/MIME cryptographic signature
____________________ Racket Users list: http://lists.racket-lang.org/users