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] |
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