[plt-scheme] Switching to Scheme

> 1.  One of Python's primary data structures is called a list, but I 
> believe is actually an auto-resizing vector.

Hi Mark,

You could probably use evector.ss from the PLaneT repository:

     http://planet.plt-scheme.org/#evector.plt1.0



> Now I'm capable of implementing a queue on my own, but for a common data 
> structure on which I will be heavily relying I always prefer to use a 
> solution that's been well thought out and "peer reviewed" to make it as 
> efficient as possible.  For example, I remember a very clever 
> implementation of queues in Okasaki's Functional Data Structures.

You might be thinking of:

     http://schemecookbook.org/view/Cookbook/FunctionalQueue



> I did a search in the PLT Help desk for "queue" but it didn't turn up 
> anything.  Is there a hidden stash of common data structures that might 
> help me out here?

There are a few places I look for Scheme snippets and documentation. 
These include Help Desk, the Schematics Cookbook, and PLaneT.



> As always, rather than rewrite my own, I'd prefer to use a standard 
> library version of the algorithm.  Is there a hidden stash of common 
> algorithms that might help me out here?

Permutations... checking... unfortunately, I'm not hitting anything that 
will help too much.  However, I've ported over an implementation of 
generators to PLT Scheme, so you can probably recode that permutation 
thing with it if you want.  I've put it in PLaneT:

     http://planet.plt-scheme.org/#generator.plt2.0


As a quick first pass, see:

     http://hkn.eecs.berkeley.edu/~dyoo/tmp/gen-perms.ss

(I'm keeping this temporarily only because the code is hideous...)



> 3.  Speaking of lazy list comprehensions, SRFI 42 appears to only be for 
> eager list comprehension.  Is there a lazy version floating around?  I 
> use list comprehension syntax all the time, and would sorely miss it if 
> I couldn't use it (even though it's all convertible to map/filter/etc.).

Not certain; I hope someone else can answer this one.  I'm still trying to 
figure out how people remember the SRFI's by their digits alone: I feel 
like I'm surrounded by MIT alumni.  *grin*




> Are there any gotchas about the way hash tables are implemented that I 
> need to be aware of?  For example, does it work best if I convert my 
> keys into immutable data (so that an eq? test will suffice)?

mzscheme's hash tables are eq? by default.  We have to go out of our way 
to make them work through equal?  See the 'equal flag passing option in:

http://download.plt-scheme.org/doc/350/html/mzscheme/mzscheme-Z-H-3.html#node_sec_3.14





> 6.  I do a fair amount of file input and output, some of which is 
> "pickling" the state of my computations and/or large data structures to 
> file for later resumption.  I know that Scheme has plenty of I/O 
> capabilities, but I'm not quite clear on how to do pickling.

The *read* and *write* primitives are supposed to be inverses of each 
other, so you can probably use those for primitive data structures.

Serializing other data types requires some hinting.  For structures, the 
seralize.ss module in mzlib (mzscheme's standard library) should do the 
trick:

http://download.plt-scheme.org/doc/350/html/mzlib/mzlib-Z-H-38.html#node_chap_38

mzscheme class instances, similarly, need to be hinted to serialize 
properly.  See:

http://download.plt-scheme.org/doc/350/html/mzlib/mzlib-Z-H-4.html#node_sec_4.7

for information on how to serialize instances.





> 7.  I generate a lot of tree structures and directed graphs.  Almost 
> certainly this stuff would actually come out a lot cleaner in Scheme.

I find myself cooking up my own versions of these darn things too.  If you 
get a good response about this, I'll be happy as well.


Best of wishes!