Re: The relationship between SCM and scm_t_bits.

[Marius Vollmer <mvo@zagadka.de>]

Dirk Herrmann <dirk@dirk-herrmanns-seiten.de> writes:

> Certainly, the way we convert between scm_t_bits and SCM is
> implementation dependent. However, the definitions for scm_t_bits
> and SCM are IMO a very good way to provide an abstraction of some of
> this uncleanlyness. And, with today's definitions of scm_t_bits and
> SCM, the heap _must_ hold scm_t_bits variables.  Please explain, why
> you think that it is cleaner to say it only holds scheme objects if
> in fact it does not.

The reason is that there exits code that does essentially this:

    scm_t_bits heap_field;

    SCM value = whatever ();
    SCM *ptr = (SCM *)&heap_field;
    *ptr = value;

This is quite unclean.  This variant is cleaner and standards
conformant:

    SCM heap_field;
    
    SCM value = whatever ();
    SCM *ptr = &heap_field;
    *ptr = value;

> What is the reason to change a paradigm, which has for several years
> worked quite nicely, is easily understood, and has helped to find
> and probably also to avoid a bunch of errors?

I don't think that the paradigm has changed fundamentally.  It has
been strengthened, if you will.  The distinction between scm_t_bits
and SCM is still there.

We don't just cast between SCM and scm_t_bits, we use SCM_PACK and
SCM_UNPACK.  Except sometimes a scm_t_bits variable is stored into via
a SCM* pointer, totally ruining the care PACk/UNPACK abstraction.
That exception has now been removed.  I see that as an unconditional
improvement, don't you?

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel