<br><br><div><span class="gmail_quote">On 5/31/07, <b class="gmail_sendername">Robby Findler</b> <<a href="mailto:robby@cs.uchicago.edu">robby@cs.uchicago.edu</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> On 5/31/07, YC <<a href="mailto:yinso.chen@gmail.com">yinso.chen@gmail.com</a>> wrote:<br>> > Am I inferring correctly that you are saying closure consumes a constant<br>> > factor of memory over struct, but otherwise doesn't necessarily hold onto <br>> > unnecessarily references from the stack?<br><br>> Right.</blockquote><div><br>Thanks. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> > > Any other way besides closure & struct to create opaque compound value<br>> > objects?<br><br>> The way we think of it: all compound values are structs at one level<br>> or another. You just may or may not have access to the inspector to <br>> see the fields. So ... no. :)</blockquote><div><br>Out of curiosity - does PLT scheme actually use struct as the fundamental compound type, i.e. implement closure/etc on top of struct.  I like structs but have problem with 1) making it anonymous and 2) that make-struct-type is cumbersome if define-struct along doesn't cut it. <br><br>Thanks,<br>yinso <br><br><br></div><br></div>