Re: guile and emacs: unexec

[Andy Wingo]

Howdy Ken!

On Sun 14 Jun 2009 07:21, Ken Raeburn <address@hidden> writes:

> On Jun 13, 2009, at 09:06, Andy Wingo wrote:
>
> Yes -- for now, that includes anything I haven't converted, including
> strings, symbols, vectors of objects, hash tables, etc.  Many of what
> are currently smobs should eventually be converted to using Guile's
> versions, either directly or with some simple wrapping.  They need to
> stay identifiable in Lisp as the correct object types, so I can't
> implement a Lisp string with, say, a Guile list containing a string
> plus text-property data.  In the long term perhaps some of them could
> be implemented partly or fully in Scheme, but I don't want to diverge
> radically while I still need to track the main Emacs code base.
> (Please let me keep the illusion that replacing the fundamental object
> representation, allocator and garbage collector, and compensating for
> initialization problems throughout the code, isn't all that radical a
> change. :-)

:-)) Sounds like a good path to me, though I know you've thought much
more about it :)

> I figure, once I've got this set of changes working correctly (i.e.,
> nearly indistinguishable, no random unexplained errors or differences
> in behavior), then I can tackle the next steps with more confidence
> that differences observed there are due to the new changes in  progress,
> not semantic differences previously introduced with further- 
> reaching effects than I expected.

Sounds like a plan.

> It's also kind of appealing to have something at intermediate stages
> that I might be able to show off, and say "hey, this works well enough
> that you can try it out; want to help me on the next steps?"  (And
> since I'm getting into all this now, I *would* like some help.  I was
> just intending to fix a few more problems before making the plea. :-)

I'm happy to help in making Guile a better implementation of Elisp than
the one Emacs has.

> I'm specifically *not* trying to do some of the other things that have
> been discussed but aren't about running Emacs -- make buffers
> independent objects that can be used outside of Emacs, stuff like  that.
> That can come later (or not), and I'd be glad to see it happen,  but
> getting Emacs running at all is a big enough project for me on my
> own.

Yes this sounds like a good plan.

>> Symbols however should probably be represented as Guile symbols, not
>> smobs. I think that you will find that with a more compilation-centric
>> approach, we will be able to keep more simple datatypes, as we compile
>> the procedures that operate on those data types to appropriate code.
>
> Eventually, yes, I think so.  They should probably be one of the next
> things to change, though some like vectors and strings might be
> simpler.  I'm also concerned about the performance impact of making
> such a switch; another reason for getting something working soon is so
> it's practical to look at performance questions.

Daniel's work looks promising in this regard -- his idea was to make
function values and symbol values resolve the same Guile symbol in
different modules. The bindings would be Guile's fluids. Compilation
would take care of the translation. Hopefully by the time you're ready,
we'll be ready with that too.

> I actually had it pretty far along once or twice before (I seem to keep
> reviving this every few years, and spend a lot of time updating  to
> newer code bases), but I think I've managed to push it a bit  further
> than I had it earlier.  With just me working on it, depending  on the
> demands of my job, there tend to be large periods when no  progress gets
> made, and it doesn't keep up with the upstream sources;  the prospect of
> having to do a bunch of catch-up work just makes it  that much less
> appealing to get back into it.  It's been moving  forward in spurts for
> over a decade now, very slowly. :-(

You know though, this whole free software thing is actually OK in this
respect. There are some technologies that just don't change very
quickly. Keisuke had a VM working in 2001, but only now in the middle of
2009 have we merged it into Guile. We'll make it :)

>> If this is an effort that you want to pay off in the future, though, I
>> would strongly suggest updating to the 1.9/2.0 series of Guile. The
>> expressive range of Guile's multilingual facilities is much higher
>> there, and significantly different from 1.8.
>
> I was looking at updating, but ran into the -I ordering problem I
> reported.  Since that's fixed, I'll try again sometime.
>
> The multilingual facilities aren't very important to me right now -- 

Ah, I was referring to programming languages ;) Human language is
another kettle of fish. Doesn't emacs support a superset of unicode?

But in general I am very sympathetic to the goal of making minimal,
correct changes.

>> OTOH, the emacs lisp support is not yet up to the level that it is at
>> in
>> 1.8, so perhaps now is not yet the time.
>
> And, I haven't started using any of that code yet, either... that's
> another big change to try at some point when everything else is  looking
> solid.  And, I assume it expects the use of Guile symbols and  Guile
> strings at least?  In order to make this switch, too, the  semantics
> really have to match Emacs Lisp -- stuff like indirect  symbols, buffer-
> or frame-local bindings, etc.  And all the Emacs C  code needs to know
> how to look up values (or function values, or  property lists, or
> whatever) when given Guile symbols.  And then  there's the lexical
> binding branch work, which I haven't even looked  at yet.

Yes we want to make that work *correctly*, exactly as Emacs does. I
think we can do it. I bet frames and buffers should also have modules,
modules that use the global function or variable modules, as
appropriate -- would provide for quite fast lookup and switching.

>>> P.S.  If anyone wants to take a look at my current work,
>>> http://www.mit.edu/~raeburn/guilemacs/guile-emacs.tar.bz2
>>> has a snapshot from tonight.
>>
>> Cool! Have you considered using git, and branching from Emacs' git
>> mirror? That way it is trivial to set up something other people can
>> comment on, in easily-digestible patch chunks.
>
> Yep, but I need to get proficient with it first, and haven't put in the
> time yet; until then I'm using subversion in a rather clumsy  fashion
> (often just checkpointing untested merges, and my Emacs  sources have
> the CVS admin files checked in so I can update easily).   If it's
> something other people want to actually work on, on the other  hand, we
> could set up something via sourceforge or savannah or  whatever.  But
> only if there's actually going to be additional help  coming....

I would suggest setting up a Git repository on savannah, branching from
the Emacs git mirror. Then I would suggest distilling your patches into
correct, standalone patches, and committing those one-by-one. This will
help Emacs developers in addition to Guile developers. It would probably
be fine to use guile-devel as your mailing list for now -- if it ever
becomes a problem (unlikely, as we all want Guile in Emacs :) we can
split out another ML.

That way people can casually contribute, and potentially become sucked
into the Emacs vortex :)

Cheers,

Andy
-- 
http://wingolog.org/