Re: [Chicken-janitors] #905: Unreliable behavior of hash tables with symbols as keys (regression wrt 4.7.4)

[Chicken Trac]

#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 felix):

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

 That makes sense. You can create a ticket for that, if you like.

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

 Is "component-name" a symbol or a symbol converted to a string in the code
 above (the one that uses `string-append`)?

 Is it possible that there is a problem with re-hashing (the process of
 enlarging the internal hash-table bucket-sequence if the capacity is
 exhausted)? Ivan: can you try creating your hash-tables with `min-load
 `/`max-load` settings that are large enough to avoid any rehashing and
 check whether this makes a difference?

 Is there an example use of nemo that can be used to reproduce the problem?

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