Re: Scheme style auto-resizing hashtable (fwd)

[Jay Glascoe <jglascoe@jay.giss.nasa.gov>]

On 25 Oct 1998, Harvey J. Stein wrote:

> Per Bothner <bothner@cygnus.com> writes:
> 
>  > A simple Scheme-style iterator:
>  > 
>  > (hash-key-iterator HASHTABLE) -> ITERATOR
>  > 
>  > where ITERATOR is a zero-argument procedure whose first call
>  > returns the first key, the second call returns the next key,
>  > and so on.  When there are no more elements, an end of file
>  > object is returned.

my thoughts exactly Per.

> 
> What does the iterator do if the hashtable is modified before it's
> gotten to the end?

it breaks.

> 
> For that matter, what do map & for-each do if the lists they're
> mapping over are modified before they reach the end?
> 

let's try it and find out.  I'll try to set up an infinite loop:

$ guile
guile> (define *el* '(1 2 3))
guile> (define screwy
...   (lambda (x)
...     (append! *el* '(foo))
...     x))
guile> (map screwy *el*)
ERROR: In procedure append! in expression

<it hangs here, hit ctrl-C>

^C
Exception during displaying of error: signal
ABORT: (wrong-type-arg)

Type "(backtrace)" to get more information.
guile> (backtrace)

Backtrace:
0* [map #<procedure screwy (x)> (1 2 3 ...)]
1* [screwy 3]
2* [append! (1 2 3 ...) (foo . #0#)]

Type "(debug-enable 'backtrace)" if you would like a backtrace
automatically if an error occurs in the future.
guile> *el*
(1 2 3 foo . #3#)

hmm. weird. where did that #3# come from?

> It's just that in your example the iterator is explicitly returned,
> making it more likely for it to be passed around & used out of scope,
> whereas with map & for-each the lists in question are typically out of
> the scope of the fcns mapping over them, so accidental modification is
> more likely.

right, Caveat Programmer, be careful.

> -- 
> Harvey J. Stein
> BFM Financial Research
> hjstein@bfr.co.il
> 

	Jay
	jglascoe@jay.giss.nasa.gov