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

From: John Clements (clements at brinckerhoff.org)
Date: Sun Nov 11 18:40:26 EST 2012

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.


-------------- 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>

Posted on the users mailing list.