guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Requests for API changes


From: Dirk Herrmann
Subject: Re: Requests for API changes
Date: Tue, 19 Sep 2000 11:36:43 +0200 (MEST)

On 15 Sep 2000, Mikael Djurfeldt wrote:

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

To clarify: scm_string_hash takes a char* and a length argument.  Thus,
you're right that its actually not a C string.  But, its not a scheme
string either.  Looking at ANSI C naming schemes, `mem' might be a good
name to use.   -->  scm_mem_hash

Currently, guile seems to use `0str' or `str0' to indicate that a C string
is given as input parameter.  For arbitrary memory regions (which may
contain \0 characters) guile uses str, and the length is given as an
additional parameter.  -->  scm_str_hash (the former name was scm_strhash)

I have not checked thoroughly whether this naming scheme is consistently
used.

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

Using the new property scheme from Marius would be the best thing, I
guess.  The point is, that I don't know if its worth the effort to
reimplement these function at all.  As Marius has pointed out, they are
used to emulate lisps name spaces for functions and variables.  Thus, I
wonder if these are actually used, or whether they are remains of some
older design of guile where direct evaluation of lisp was a goal?

Further:  I don't think it's a good idea to use the fourth slot in the
symbols' cell.  This means to mix two different concepts, which in the
long run will cause trouble.  For example, a switch to a different string
representation (using copy-on-write) seems ahead, which may require to
change the symbol layout again.  If we keep different issues separate more
cleanly, such design changes will cause less problems.

> > 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!  :-)

Somehow I knew that :-)  But, what would be better and still sufficiently
explicit?  scm_makstr creates a scheme string of a given length, but does
not initialize the characters.  scm_makfromstr gets a pointer to a memory
region and a length.  A copy of the memory region is made, and this region
is used as the character field of the freshly created scheme string.

A potential set of functions to make a scheme string could hold the
following variants:

make a scheme string from:
- a copy of a cstring (= a \0 terminated memory region)
- a cstring without copying.  The scheme string becomes the owner.
- a cstring without copying, but the scheme string does not become owner.
- a copy of a memory region
- a memory region without copying.  The scheme strings becomes owner.
- a memory region without copying, no transfer of ownership.

(In addition, for each of these there is the additional option to create
an immutable or a mutable string.)

Ownership means, that if the string gets garbage collected, it has to free
the corresponding memory region.  The point of not transfering ownership
is interesting for strings that are made from character constants.  These
have not been obtained via malloc and thus may not be freed.  However,
there might be other situations where this makes sense.

I don't know if it makes sense to provide such a large set of different
functions to create strings.  Certain things can also be left to the
user.  For example, the copying of the memory region (if desired) can be
expected to be done by the user, which would simplify that interface, but
would require to add convenience functions for copying cstrings and memory
regions.

BTW:  A similar set of functions could be provided to create symbols as
well ...

Which leads to the question, whether a distinction between a type to
represent fixed length character fields, and the different types that use
such a representation (symbols, strings, ...) would make sense.


Best regards
Dirk



reply via email to

[Prev in Thread] Current Thread [Next in Thread]