Re: GRM questions

[Dirk Herrmann]

On Tue, 29 May 2001, Martin Grabmueller wrote:

> * Validation macros:
> 
>   Are they stable enough and have they been agreed on, so that they
>   could be documented?  I think about adding a section dealing with
>   parameter validation.

Huh, well, they are used all over guile, but IMO, there's a lot of strange
things going on there.  Who's afraid of SCM_VALIDATE_SUBSTRING_SPEC_COPY,
SCM_VALIDATE_INUM_MIN_DEF_COPY, SCM_VALIDATE_NONEMPTYLIST_COPYLEN,
SCM_VALIDATE_NULLORROSTRING_COPY?  I am :-)

The error messages that they deliver are also quite strange.

The point is, that I don't have a better solution at hand.  Still I hope
that some day we will find one...

>   The examples and description use the notion of CDR for the data slot
>   of smobs.  Shouldn't that be changed to
>   SCM_CELL_WORD/SCM_CELL_OBJECT?  [...]

Yes, please.

> * In node `Garbage Collecting Smobs':
> 
>      Note that, since a smob's mark bit lives in its CAR, along with the
>   smob's type tag, the technique for checking the type of a smob described
>   in *Note Typechecking:: will not necessarily work during GC.  If you
>   need to find out whether a given object is a particular smob type
>   during GC, use the following macro:
> 
>    - Macro: void SCM_GCTYP16 (SCM X)
>        Return the type bits of the smob X, with the mark bit clear.
> 
>        Use this macro instead of `SCM_CAR' to check the type of a smob
>        during GC.  Usually, only code called by the smob's `mark' function

These paragraphs are no longer valid.  You can simply remove them.

> * In node `Describing a New Type':
> 
>      Instead of using `scm_make_smob_type' and calling each of the
>   individual `scm_set_smob_XXX' functions to register each special
>   function independently, you can use `scm_make_smob_type_mfpe' to
>   register all of the special functions at once as you create the smob
>   type(1):

scm_make_smob_type_mfpe is (or should be) deprecated.

Best regards,
Dirk Herrmann