This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: scm_bits_t
- To: Dirk Herrmann <dirk at ida dot ing dot tu-bs dot de>
- Subject: Re: scm_bits_t
- From: Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>
- Date: 14 Mar 2000 18:57:19 +0100
- Cc: Guile Mailing List <guile at sourceware dot cygnus dot com>, djurfeldt at nada dot kth dot se
- Cc: djurfeldt at nada dot kth dot se
- References: <Pine.LNX.4.21.0003141645350.13413-100000@marvin.ida.ing.tu-bs.de>
Dirk Herrmann <dirk@ida.ing.tu-bs.de> writes:
> Is there a policy for guile that states whether it is allowed to
> break backwards compatibility, and when?
There are a set of Guile policies, but I don't think they are written
down. Perhaps we could have a special development directory under
guile-core at the CVS repository where we could write down policies,
collect proposals etc.
> 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 think I actually consistently would try to use lower-case letters
for types.
> > 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 :-)
But then I would no longer be able to run elisp programs in Guile.
Actually, that code contains a set of interesting ideas, for example a
solution to the separate namespace problem, and an implementation of
shallow binding in Guile.
I'd like it to be there until we have clearer ideas about just how
Guile is going to support language translation.