[plt-scheme] structures and named let (two questions, more or less)

From: Carl Eastlund (carl.eastlund at gmail.com)
Date: Fri Feb 24 16:42:26 EST 2006

On 2/24/06, Greg Woodhouse <gregory.woodhouse at sbcglobal.net> wrote:
> 1. Is binding a hash-table via let like this expensive? The structure
> could be quite large. What about consing a list containing the
> hash-table and passing that to another function? (Okay, I guess that's
> already two questions.)

Once you've created a hash-table, "putting" it anywhere - in a
variable binding, in a cons cell, passing it to a function - is cheap.
 DrScheme maintains only one copy of it, and passes it around by

> 2. What if I require struct.ss and use copy-struct to create a new
> environment? That seems attractive because it doesn't involve any
> mutation, but absent any compiler optimizations, it could involve a lot
> of copying. I guess what I'm really asking is this: If a structure is
> immutable and I update a copy, am I really copying the underlying data?

The only thing copy-struct copies is the top-level struct (you'll need
to use a known struct type, you can't magically copy unknown
structures).  So if you made your own list type (like cons, but with a
new name like make-my-cons) and tried to copy your list, only the
first cons cell would be copied and it would have links to the same
remainder as the original list.

So it would be a cheap implementation, space- and time-wise, but if
you really want a separate copy of a whole data structure it won't do

> (Okay. I'll throw in a third question because it's something that's
> been bugging me: How come all the libraries end in .ss? Is that a
> convention for modules?)

That's just the filename.  Just like text files end in .txt and Word
documents end in .doc, someone decided Scheme files should end in .ss
(when they don't end in .scm).  So all our modules follow that
convention, and the module system knows that the file "foo.ss" should
have a module defined as (module foo ...).

Carl Eastlund
"Cynical, but technically correct."

Posted on the users mailing list.