Requests for API changes

[Dirk Herrmann]

Hi!

Looking more deeply into the question how the environments can be
integrated into guile, I found the following things which IMO should
better be changed:

* in symbols.c: scm_strhash.  The function determines a hash value for a
  string.  However, it does not return the 'raw' hash value, but already
  performs the modulo operation to make it fit for a certain hashtable
  size.

  I'd rather have the function _not_ perform the modulo operation, but
  leave this to the caller.

  Reason:  Symbols carry their hash values with them.  This makes sense,
  since symbols are likely to be used in all kinds of hash tables.  For
  example, when interning symbols, the hash value is used.  And,
  the environment hash tables use that value as well.  But, currently the
  hash value that symbols carry around is already adjusted to the size of
  the hash table that is used for interning the symbols.  Therefore, if
  symbols are used in hash tables of different sizes, the chance for hash
  conflicts is increased.  Thus, it would be better if symbols carried the
  raw hash value with them and have the modulo operation be performed at
  the time when the actual hash table size is known.

  Since the function scm_strhash is the place where hash values for
  strings and symbols are calculated, it would be of more general use if
  this function returned the raw hash value.

  Thus, I suggest to change the function from
    unsigned long scm_strhash (const unsigned char *, scm_sizet, unsigned long);
  to
    unsigned long scm_strhash (const unsigned char *, scm_sizet);
  i. e. not passing the modulo operand.

* SCM_SYMBOL_FUNC and SCM_SET_SYMBOL_FUNC should be removed.  These macros
  are used to implement a 'function' property for symbols.  In some
  comment it says that this is used for lisp compatibility.  This,
  however, is not used throughout guile-core.  I haven't checked the other
  guile cvs modules, but in any case we should use the general object
  property mechanism instead.  Together with these, we could also get rid
  of the corresponding functions scm_symbol_fref (= symbol-fref) and
  scm_symbol_fset_x (= symbol-fset!).  Even if their functionality was
  still needed, this was a good moment to change the names to something
  that is more readable.  Or, drop them and use the generic property
  interface.

* SCM_SYMBOL_PROPS and SCM_SET_SYMBOL_PROPS should be removed.  These
  macros are used to implement all other kinds of symbol-properties.
  Again, the generalized property mechanism should be used instead.  And,
  scm_symbol_pref and scm_symbol_pset_x could be eliminated as well.

If these changes are accepted, the handling of symbols would be much
simpler.  Then, I would like to change the current symbol representation
to use a double cell, which holds the type tag (including length), the
pointer to the string representation, and the raw hash value.  Thus,
symbols and strings could still be treated alike.

Best regards,
Dirk