This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Scheme is too complicated


Jay Glascoe writes:
> > I'd like to see *one* dictionary-like structure that is good enough to
> > replace all of these.  It should be fast and robust.
> 
> my hash tables are fast, but not 100% robust: the table breaks if the user
> accidentally (purposefully ?) mutates one of the keys, e.g.
> 
> (define foo '(1 2))
> (dictionary-add! my-dictionary foo "biz")
> (set-car! foo "jeepers!")
> (dictionary-lookup my-dictionary foo)
> #f ;; i.e., the dictionary thinks it isn't there

I can't see how you'd get around that, without having some sort of
mechanism to tell when foo is modified or to make foo unmodifiable.
Putting a trace on foo is too hard and not worth it by a long shot.
Making it unmodifyable might be kind of nice... but either way it's
not really worth the effort.  Users just shouldn't do that sort of
thing.  I guess this makes it not completely robust, but only
depending on how you define what you are trying to do.

> > So it should print all pretty and be printed in a non-ambiguous manner
> > so that it can be reread from that printing, for instance. 
> 
> my hash tables are extended Scheme types, i.e.
> 
> basic Scheme type:    numbers, booleans, characters, the null list, etc.
> extended Scheme type: all basic Scheme types, any pair or vector of
>                       extended Scheme types
> 
> they look like this
> 
> (#(hashtab 3 #t #t) . #(((459024808 "biz" . "bizeroni") (-157169068 "pep"
> . "peperoni")) () () ((305423011 "froggy" . "froggieroni"))))

Is there a mechanism to make a new type, or are all extended types
going to be these sorts of ad-hoc pasting together of information?

Judging from the hash-table representation, the only way to tell a
hash-table from some other vector is by usage.  That means there isn't 
any pretty printing for hash-tables, all functions on hash tables must 
be "hash-*", and other unattractive things.

It seems like this would be an argument against calling Scheme/Guile a
VHLL.  When a vector is no longer a vector (i.e., has significantly
more internal structure) it shouldn't be a vector.  It deserves its
own type.


...
> I would prefer to hide the keys' hash values from the user.  I plan to
> have, e.g.
> 
> dictionary->keys
> dictionary->values
> dictionary->pairs

Yes, hash values aren't something users need to look at.  If it really
is a "dictionary" and not a hash-table, then the hash values should be
completely hidden (as an implementation detail).  I think
dictionary-map, dictionary-foreach, dictionary-map-association,
etc. are also good function to have.  Just about everything that can
be done to lists can be done to a hash table (though it can be done in
two ways, i.e., by value or by association/pair).

I don't think having "keys" is too important.  The key shouldn't be
important except with respect to the value it is associated with.  And 
even if someone does want just the keys, they can get the pairs and
get the key from that.

To a degree, I think it's analogous to someone wanting to get all the
indexes for a vector.  This is used, vector-length (which implies all
the other indexes) gives this.  The only place where I can see this
getting used is when you iterate over the vector -- but dictionary-map
et. al. should suffice for these needs.  Is there anyplace else where
vector-length is used that's not to get the size of the vector (which
is another concept)?

...
> any C extension providing procedures to operate on extended Scheme types
> (my extension meets this description) could be entirely implemented in
> Scheme (with modest to not-so-modest performance penalties).  The best
> approach may be to keep the compute intensive operations (e.g.,
> dictionary-add!, or the internal resize procedure) in C and
> write the rest in Scheme.

I see the reasons for the Scheme source being for debugging (where
speed is usually not too important) and pedagogy (where the source is
around to be read, not necessarily run).

In these cases, it's not so important to worry about performance, but
more about the ability to transparently have visible Scheme source but
a C implementation (with the possibility of using the Scheme source as 
the implementation).


<------------------------------------------------------------------->
< Ian Bicking                 |  bickiia@earlham.edu                >
< drawer #419 Earlham College |  http://www.cs.earlham.edu/~bickiia >
< Richmond, IN 47374          |  (765) 973-2824                     >
<------------------------------------------------------------------->