[Top][All Lists]

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

Re: smob cleanup

From: Dirk Herrmann
Subject: Re: smob cleanup
Date: Fri, 8 Dec 2000 01:35:44 +0100 (MET)

On 7 Dec 2000, Keisuke Nishida wrote:

> Dirk Herrmann <address@hidden> writes:
> > > I have made a patch as follows.  I'll check it again later on before
> > > committing.
> > 
> > Very nice!  One small point, though:  I think that scm_bits_t _is_ the
> > right type for the scm_tc16_* variables.  The reason is the
> > following:  SCM_TYP16 (x) will deliver (SCM_CELL_TYPE (x) & 0xffff), and
> > SCM_CELL_TYPE is of type scm_bits_t.  All the places where long was used
> > are probably older, and the same is true for scm_make_smob_type.
> Hmm, what about defining scm_type_t for clarify?
>   typedef scm_bits_t scm_type_t;

We once had a discussion about the name, but we did not come to a clear
conclusion.  scm_type_t, scm_t, scm_word_t etc.:  There were a lot of
different possibilities.  I also think that scm_bits_t is not the best
name to choose, but we should for the time being just keep it.  It has at
least one benefit:  It is so unique that changing it could simply be done
by using s/scm_bits_t/<a better name>/.  Thus, I say don't add an
_additional_ name except you are planning to replace everything

You probably know about the file doc/api.txt, where SCM and scm_bits_t are
described as the two basic types in guile?  We should try to keep it this
way, even if one day we are going to rename one of them (or both :-)

> And I think it would be great if there were some convention of smob type
> definitions.  I have rewritten example-smob/image-type.[ch] in my style
> as follows.  Is it a good thing to modify some of Guile's code in this
> manner?

I like the clean style that you are proposing.  For a tutorial about how
user code could look like it is really great.  However, since you asked
whether guile itself should be modified in that way, there are some points
about it:

* using SCM_SMOB_PREDICATE is definitely very clean from a stylistic point
  of view, but it has the disadvantage that you must include smob.h with
  every header file that uses it.  Hmmm.
* your code adds bindings to the scheme level by using scm_make_gsubr.
  I assume that this is just for the tutorial.  In guile we should try to
  use SCM_DEFINE or at some later point the new versions of these macros.
* I'm not sure yet whether using type tag names like scm_image_type is a
  good idea for within guile.  From the user's point of view, it's
  irrelevant, since the user should be able to do anything of interest by
  using the macros.  But, to keep an overview over guile's type tagging
  structure, names like scm_tc16_<foo> make some sense.  Maybe we find a
  better naming solution for these tags one day, but for now I think we
  should keep them as they are.

BTW, we should also think about a clean and consistent way to check for
parameter errors and other kinds of errors.  Currently, the VALIDATE
macros make things easier, but as Mikael wrote in a mail, the error
messages that these write out can be quite strange...

In any case, thanks for the much improved example code.


reply via email to

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