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 style auto-resizing hashtable (fwd)


On Thu, 19 Nov 1998, Ian Bicking wrote:

> Jay Glascoe writes:
> ...
> > hmm.  I could make them destructive as well as functional.  I mean, "list"
> > will still be destroyed -- it's finally reduced to (()) -- but rather than
> > directly converting "list" to a hash-table, the new hash-table will be the
> > return value of the function.  Would this be preferable to in-place
> > transformation?  I like the idea, now they'll work fine with empty lists.
> 
> The opposite of imperative isn't functional.  It's the "!" which isn't 
> functional.

I'm using "functional" as the adjectival form of "function".  One of the
properties of a function is that it has a return value. 

> Mutation/destruction is the opposite of functional -- it just so happens
> that imperative style is useless without mutation (after all, if you
> don't use the resulting value of a side-effect-free procedure, why call
> the procedure at all?) 

Yes, but then a purely functional program is also useless without
mutation.  E.g. it must perform some IO, thus changing the state of
something (the file, my screen, the speaker ...), if it is to communicate
with the outside world. 

> You shouldn't be destroying the source collections, IMHO.  That's what
> the garbage collector is for.  Not only is it easier for the garbage
> collector to destroy the old list, it is safer.

Yes it's safer, but when will it collect?  Do you really think it's going
to start collection in the middle of a "list->hash-table" operation?  The
whole idea behind "list->hash-table!" and friends was to keep the space
overhead at a minimum. 

> > In addition to the space-saving virtues of the destructive functions, they
> > also ensure that the new hash-table or list is the sole owner of the pairs
> > contained in the old list or hash-table. (assuming nobody else is holding
> > onto the pairs).
> 
> That last little caveat isn't to be ignored!

the pairs/associations themselves are left untouched.  If something is
pointing to some part of "list" (like its cdr), then yes, that thing too
will be changed.  It's really no different from "set-cdr!" or something. 


	Jay Glascoe
	jglascoe@jay.giss.nasa.gov