[plt-scheme] Switching to Scheme

On 6/30/06, Danny Yoo <dyoo at hkn.eecs.berkeley.edu> wrote:
> > 1.  One of Python's primary data structures is called a list, but I
> > believe is actually an auto-resizing vector.

> You could probably use evector.ss from the PLaneT repository:
>
>      http://planet.plt-scheme.org/#evector.plt1.0

Yes, this is a great starting point.  Thanks for the pointer to that.
It's pretty close to what Python offers.  There are a handful of
common, useful functions missing from the implementation (slices, push
and pop from the end, sort, reverse, etc.), but these are easy enough
to add on top of what's already there.

> You might be thinking of:
>
>      http://schemecookbook.org/view/Cookbook/FunctionalQueue

Thanks so much for mentioning the schematics cookbook.  I hadn't seen
that site.  It's got a lot of great information in it.

> 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

Excellent.  That will be another useful tool for porting Python code.
I use generators all the time.  (I suspect that Scheme has some even
better constructs for developing lazy data structures.  I'm already
aware of the built-in stream primitives.  Are there some other useful
ways of creating laziness?).

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

Upon closer inspection, it looks like eager list comprehension was
what I wanted.  Even though the generated list is not lazy, the
comprehension properly deals with lazy generators to build the list in
a space-efficient way.

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

I understand that eq? is the fastest way to compare, but it offers
very little guarantee that it makes meaningful comparisons.  According
to the standard, there's even no guarantee that (eq? 2 2) will return
true.  So which things are safe to use as keys for the eq? style
hashtable?  Can strings and/or lists be easily converted into
something that can be compared with eq?

Thanks,

Mark