[racket] TR memory optimization: 240 Bytes of garbage for calling TR?

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4370 bytes
Desc: not available
URL: <http://lists.racket-lang.org/users/archive/attachments/20121111/09b10cf2/attachment-0001.p7s>