Re: Scheme style auto-resizing hashtable (fwd)

[Ian Bicking <ian@earlham.edu>]

Tel writes:
...
> > The opposite of imperative isn't functional.  It's the "!" which isn't 
> > functional. [and so on]
> 
> 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. [and so on]

I certainly wasn't arguing that imperative programming should be
shunned.  I was only being picky about the proper use of the word
"functional".  

> 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 can't agree with this.  Scheme "protects" me from accessing past the
end of a vector: I am glad it does this, even though it would not be
necessary if I just wrote my programs correctly.

Scheme also doesn't give any access to pointers, pointer arithmetic,
or any thing like that.  This is clearly a manner of protecting the
programmer from his or her flawed, but well-intended desires to mess
directly with memory.  It keeps a wide variety of difficult and common 
bugs from coming about.

On the same vein, part of Scheme's power comes from functional
programming constructs -- that transformations shouldn't (generally)
destructively change the data they work on, because somewhere else you
might still be using that data.  Destructively changing data to update
it is much different, mind you, because the data has the same meaning
and form as before, but is changed to reflect a changed state.  A
transformation (such as alist->hash-table) is not an update but a
change of form or meaning.

Now, you can verify that you aren't using that data anywhere else, but 
that is *exactly* what the GC is doing.  On the downside, the GC is
doing that at runtime, slowing execution.  On the upside, the GC is
doing that at runtime, with full knowledge of the actual state of the
program.

Now, it's true you can get faster without GC but I really don't think
this is what Scheme is -- that's what C is.  And you can write that C
code if you care to and link it to Guile.  If you are writing really
time-critical code this is probably a good idea.  Considering the time
issues, it would seem like a bad idea to try to optimize code by doing
bad (and dangerous) tricks in Guile instead of transfering some code
to C.

But, of course, this is a moot issue since the destructive form didn't 
actually turn out to be an efficiency gain.


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