Re: Requests for API changes

[Dirk Herrmann]

On 10 Sep 2000, Marius Vollmer wrote:

> Dirk Herrmann <address@hidden> writes:
> 
> >   I'd rather have the function _not_ perform the modulo operation, but
> >   leave this to the caller.
> 
> Agreed.
>  
> > * SCM_SYMBOL_FUNC and SCM_SET_SYMBOL_FUNC should be removed.
> 
> Agreed.
> 
> > * SCM_SYMBOL_PROPS and SCM_SET_SYMBOL_PROPS should be removed.
> 
> Agreed!
> 
> However, as always, we should make sure that the change is handled
> gently for gthe user.  That is, first deprecating the feature before
> removing if completely.

I have in the meantime done the following:

* provided a new function scm_string_hash and deprecated scm_strhash.  I
  am thinking about renaming this to scm_cstring_hash, since it takes
  a C string as its parameter.  (Might be a sensible naming pattern in
  general.)
* unified ssymbols and msymbols such that there is now only a single
  symbol type scm_tc7_symbol.  The former symbol tags (scm_tc7_ssymbol,
  scm_tc7_msymbol and scm_tcs_symbols) are deprecated and for the meantime
  defined as scm_tc7_symbol.
* the unified symbol type uses a double cell and still stores the symbol's
  func property and the other properties with the symbol.

I have not yet deprecated SCM_SYMBOL_FUNC and friends.  The question is,
how these should be cleanly replaced?

Further:
With the new symbol representation, there is no need for the 'slot'
parameter for the functions scm_makstr and scm_makfromstr.  There does not
seem to be a clean way to remove that parameter and still keep everything
downward compatible, except by introducing new functions with different
names and deprecating the old ones.  Is this the way to go, and how should
the functions be named?  A verbose, but exact naming would be:

* scm_make_uninitialized_string (scm_sizet len) for scm_makstr,
* scm_make_string_from_copy_of_cstring (const char* src, scm_sizet len)
  as the replacement for scm_makfromstr.

Hmmm?

Best regards,
Dirk