Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Rob Browning <rlb@defaultvalue.org>]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

> on the other hand, i am eager to resolve the SCM_VCELL removal issue in
> favor of allowing minimal changes to C source.

For at least the next release of guile, it's unlikely that we're going
to have completely smooth transitions -- guile has a lot of
accumulated cruft, some from it's origins, and some because until
recently we were on a very different (and ambiguous) path with respect
to the gh_ interface, an interface which now should be going away in
it's *entirety* in the not too distant future.  Heck until we finish
the _I_ _i_ renamings, there wasn't even any way for anyone to *know*
when they were using soemthing they shouldn't have been, but that
doesn't mean we're planning to support the entire exposed interface
going forward.

IMO the process of dropping all this cruft and cleaning things up may
be a bit painful, but I think it's far better than maintaining all of
it into the indefinite future, and this shouldn't be a continual
problem.  Once we finish one or two more releases with heavy cleanup,
guile should be much less jarring from release to release.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

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