Re: scm_bits_t

[Dirk Herrmann <dirk at ida dot ing dot tu-bs dot de>]

On 14 Mar 2000, Mikael Djurfeldt wrote:

> I understand what you mean, but I think scm_t (note how this leads to
> a double meaning of scm_ in Guile) would be suitable for the basic
> scheme type which is now called SCM, but not for the type we're now
> talking about.  It seems silly to say "to access the bitstructure of
> an SCM value, use lower-case with a _t appended".

True, it has a certain 'sillyness' :-)

> (Or?  Maybe this is the way to go: "SCM" for the basic scheme type and
>  "scm" when accessing it as a number.  It is at least symmetric.)

That sounds like a very good solution.  However, it might break user code,
since there could be variables named scm.  Is there a policy for guile
that states whether it is allowed to break backwards compatibility, and
when?

Let's dream a little:  If the world was new and we were free from
backwards compatibility issues, would you rather have 'scm' be the
user-level type and SCM the internal one?  Or would you even prefer scm_t
and SCM_t or SCM_T?

I'm not sure which solution I'd favor.  I guess I could live with all of
them.  I would prefer, however, the lowercase names for the user-level
types and the uppercase variants (SCM or SCM_t but not SCM_T) for the
scheme-value-as-number types:  scm/SCM or scm_t/SCM_t, probably even the
latter combination.

> This is experimental code which originally wasn't intended to be
> included into Guile.  It was put there to make it easier for
> interested people to lab with ELisp support.  I'll rename it to
> scm_lisp_t.

Thanks.  If there is nobody using this code, I would even suggest to
completely get rid of it, before somebody starts to actually use it :-)

Best regards
Dirk Herrmann