Re: Requests for API changes

[Mikael Djurfeldt]

Dirk Herrmann <address@hidden> writes:

> * provided a new function scm_string_hash and deprecated
>   scm_strhash.

Good.

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

How do you mean?

I hope scm_cstring_hash doesn't take C strings as parameter.  They are
terminated by '\0', but Guile symbols can contain this character.

And, since it doesn't really take C strings in its full sense, maybe
it isn't such a good name after all?

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

Great.

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

Can't we use Marius' new properties?

(Also, after having introduced GOOPS, we can nicely optimize Marius'
 properties and actually use the fourth property list slot in the new
 symbols, but use it beneath Marius' interface.)

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

Sounds like a good idea.  scm_makstr and scm_makfromstr isn't the best
names one can think of.

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

No!  :-)