chicken-janitors
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-janitors] #905: Unreliable behavior of hash tables with sym


From: Chicken Trac
Subject: Re: [Chicken-janitors] #905: Unreliable behavior of hash tables with symbols as keys (regression wrt 4.7.4)
Date: Sun, 26 Aug 2012 12:28:43 -0000

#905: Unreliable behavior of hash tables with symbols as keys (regression wrt
4.7.4)
-----------------------------+----------------------------------------------
  Reporter:  iraikov         |       Owner:  sjamaan 
      Type:  defect          |      Status:  assigned
  Priority:  critical        |   Milestone:  4.8.0   
 Component:  core libraries  |     Version:  4.8.x   
Resolution:                  |    Keywords:          
-----------------------------+----------------------------------------------

Comment(by iraikov):

 Hi Peter,

 I must admit that I am ignorant of what "uninterned symbols" are, and
 neither the Chicken documentation nor the R5RS document explain this very
 well. R5RS has an exceptionally vague paragraph about "some
 implementations" that support or use uninterned symbols, and while the
 Chicken manual does list gensym under the section "Generating uninterned
 symbols", it does not specify what an uninterned symbol is. If indeed eq?
 does not hold for these symbols, I think such an important caveat needs to
 be featured prominently in the documentation. Would you be willing to add
 this to the manual?

 And yes, unfortunately my example was a bit too simplified and does fail
 on 4.7.4 as well. However, I have just done a number of clean compilations
 of nemo with Chicken 4.7.4 and 4.8.0rc2 and can again confirm that
 4.8.0rc2 hash tables with symbols as keys fail to find any of their
 elements after the tables are populated and several lookups are performed.

 The symbols in nemo can be created as constants (e.g. '* '+ '/ for the
 basic arithmetic operators), by the expression parser (which uses
 string->symbol) or by the  scope resolution machinery, which uses
 constructs of the form {{{(string->symbol (string-append component-name
 ":" (symbol->string var-id))}}} where component-name is produced with
 gensym and var-id is produced with string->symbol. Hash table look ups can
 fail on any of these symbols, it seems to largely depend on the machine
 where the program is run. So this is indeed a tricky bug and any advice on
 how to track it down would be appreciated.

 Replying to [comment:3 sjamaan]:
 > Hi Ivan,
 >
 > Perhaps I'm missing something, but you're using gensyms here.  Those are
 uninterned, which means that any gensym'ed symbol is not {{eq?}} to a
 user-inserted symbol with the same printed representation. See this
 slightly modified version of your code:
 >
 > {{{
 > (use srfi-1 srfi-69)
 >
 > (define t (make-hash-table hash: symbol-hash))
 >
 > (hash-table-set! t 'k1 1)
 > (hash-table-ref t 'k1)
 >
 > (for-each
 >   (lambda (k v)
 >     (printf "hash-table-set! ~A ~A~%" k v)
 >     (hash-table-set! t k v)
 >     (when (= v 9) ;; modification starts here
 >       (printf "Referencing ~A => ~A~%" k (hash-table-ref t k))
 >       (printf "Referencing ~A => ~A~%" 'k15 (hash-table-ref t 'k15))))
 >   (list-tabulate 10 (lambda (i) (gensym 'k)))
 >   (list-tabulate 10 (lambda (i) i)))
 >
 > (print (hash-table->alist t))
 > (print (hash-table-ref t 'k15))
 > }}}
 >
 >
 > For me, this prints:
 >
 > {{{
 > hash-table-set! k24 0
 > hash-table-set! k23 1
 > hash-table-set! k22 2
 > hash-table-set! k21 3
 > hash-table-set! k20 4
 > hash-table-set! k19 5
 > hash-table-set! k18 6
 > hash-table-set! k17 7
 > hash-table-set! k16 8
 > hash-table-set! k15 9
 > Referencing k15 => 9
 >
 > Error: (hash-table-ref) hash-table does not contain key
 > k15
 > #<hash-table (11)>
 > }}}
 >
 > This is exactly as expected.  Are you using gensyms in your actual
 program?

-- 
Ticket URL: <http://bugs.call-cc.org/ticket/905#comment:7>
Chicken Scheme <http://www.call-with-current-continuation.org/>
Chicken Scheme is a compiler for the Scheme programming language.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]