[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Requests for API changes
From: |
Dirk Herrmann |
Subject: |
Requests for API changes |
Date: |
Wed, 6 Sep 2000 23:02:18 +0200 (MEST) |
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
- Requests for API changes,
Dirk Herrmann <=