This is the mail archive of the guile-emacs@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: guile and emacs



If you want to see my implementation of the Guile multi-byte API,
check out jimb_mb_branch_1 of the guile-core module.

The internal representation is meant to be *identical* to that used by
Emacs 20.4, except for composed characters, which Guile will never
implement, and which even Emacs is removing in favor of a different
implementation.


I don't know Sperber's objections to conservative GC, but if it's the
usual fear that pointers will get dropped, or garbage will be
preserved, my experience with Emacs and Guile is that explicit root
marking is in practice *more* prone to GC-related bugs, by a large
margin.  I think that explicit root marking is impractical without
software tools to help verify that you've done things right.

For example, note that the code below is incorrect in Emacs.  Assume
all functions return Lisp_Object values:

	foo (bar (), baz ())

Suppose the compiler calls bar first, then baz.  While baz runs, foo's
frame holds a reference to bar's return value --- possibly the only
one.  If collection can occur in baz, then bar's return value will be
collected.  Instead, you must write:

	{
	  Lisp_Object temp = Qnil;
	  GCPRO1 (temp);

	  temp = bar ();
	  foo (temp, baz ());
	}

But for anyone who has not worked on both Guile and Emacs, these
arguments are anecdotal, and the usual way of thinking about program
design suggests the opposite conclusion.  So I don't know what to do.
Any suggestions?

I guess this is an inappropriate forum for this.  But I don't know
anyplace else where the choice between conservative and explicit root
marking becomes such an immediate issue.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]