This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: scm_bits_t
- To: Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>
- Subject: Re: scm_bits_t
- From: Dirk Herrmann <dirk at ida dot ing dot tu-bs dot de>
- Date: Tue, 14 Mar 2000 18:36:08 +0100 (MET)
- cc: Guile Mailing List <guile at sourceware dot cygnus dot com>, djurfeldt at nada dot kth dot se
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