Re: Scheme style auto-resizing hashtable (fwd)

[Tel <telford@eng.uts.edu.au>]

> > > Destructive conversion functions are a bad idea and cannot
> > > generalize. Taking advantage of the fact that a hash table is
> > > fundamentally a cons cell will make things lose big if you ever change
> > > your underlying implementation, for instance.
> > 
> > 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.  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?)

I agree that anything that can have side-effects isn't functional,
however I don't agree with the puritanical attitude that scheme should
somehow be a functional language. It CAN be used as a functional language
and no one is FORCING you to use destructive functions. Putting an `!'
on the end of side effect producing functions is a good idea, because it
make it obvious to the reader where the side effects are, but please, please
stop this foolishness of protecting the programmer from himself/herself --
that road leads to people getting frustrated and finding a better language
to work in.

I'm sure that most people can look at documentation that says ``destructive''
and realise that this means something gets destroyed. If the programmer
likes the idea of that then they have a right to use it -- who is writing
this program anyhow?

> The garbage collector is smart,
> programmers have repeatedly been found not to be smart enough (since
> they have to analyze these things before runtime).  Isn't something
> like >50% of bugs result from mistakes in memory-management (in
> non-GCed languages)...?

We would LIKE the garbage collector to be smart but when speed is an
issue or even memory efficiency, it has been proven to not be smart enough.
Now I am in agreement that time and human effort will gradually produce
smarter garbage collectors just like it produced smarter optimisers in
C compilers. However, even today there are times when rewriting critical
routines in assembler gives a performance boost over what a compiler can
do and there are still times when it's worth a trick or two to generate
less garbage. That day when human thought has been ruled out is not
quite here yet. Purity and holiness doesn't get the answer to the problem
out of the door by close of business.

> Maybe it's not optimally efficient, but then Scheme isn't C.  It's not 
> supposed to be optimally efficient, it's supposed to be a little
> safe.  Garbage collection is a big part of this.

Scheme is whatever the programmer wants it to be.

	- Tel