Re: Elisp development news

[Ken Raeburn]

Sorry, I've been offline a few days due to a cracked system... :-(

Neil Jerram <address@hidden> writes:
>     Ken> Having more of it in C also means less work in the event that
>     Ken> someone tries to port it to a different Scheme system -- or
>     Ken> replace Guile's Scheme engine.
> I presume you meant "less ... less" here rather than "more ... less".

Yes, exactly.

> I think Alex Shinn has started looking at multibyte strings now for
> Guile.

Great news!

> Just as long as we're not wasting our time because someone somewhere
> has changed the long term plan without telling us!

That's assuming there is a single long-term plan.  My sense is that
the Emacs maintainers were not all of one mind about this.  But with
the recent change in maintainership, perhaps we should put out feelers
again and see.

Like I indicated, my long term "plan" has been to try to get something
working well enough to demonstrate to the Emacs folks that it's
practical and beneficial to make the change.

>     Ken> (The benefits I keep hoping for are multithreaded programming
>     Ken> in elisp, and being able to do stuff through the UI while
>     Ken> work is being done in other threads.  Like editing while Gnus
>     Ken> fetches mail and news from multiple sources in parallel,
>     Ken> without having to rewrite absolutely everything to be
>     Ken> event-driven.  But multithreaded support and dynamic binding
>     Ken> handling and fast execution aren't an easy combination.)
>
> Hmmm.  I wonder if coop threading and async I/O would be enough to do
> the trick in most cases here?

Mostly, as long as it's done below the Lisp level.  With Emacs dynamic
bindings presumably being per-thread, I'm not convinced it's all that
easy to do quickly.  And coop threading wouldn't take advantage of
both CPUs in my machine.

> Variable aliases???  What are they?

  (defvar x 123)
  => x
  (defvaralias 'aa 'x)
  => x
  aa
  => 123
  (setq aa 42)
  => 42
  x
  => 42

>     Ken> Yes.  The Emacs 21 work and some changes in Guile have pushed
>     Ken> me back quite a ways, and caused me to devote all my time to
>     Ken> making the main Emacs code less dependent on the Lisp object
>     Ken> representation (outside of the lisp engine itself of course).
>     Ken> But with the release out, I've started trying to push forward
>     Ken> again.  I had, at one point long ago, an Emacs that would run
>     Ken> using the Guile object representation for numbers and cons
>     Ken> cells, and smobs for most other stuff; it had some bugs that
>     Ken> needed to be worked out.  Right now, I'll be happy when I get
>     Ken> back to the point of having it all compile once again. :-(
>
> Good luck then!  Anything that I could you help with in this area?

Probably lots of things....  Now that the Emacs repository is (I
think) open, I should be able to make an updated version of my code
available.  I'll try to do this soon, and let people know what the
status is.

>     >> - Character syntax is `?a' rather than `#\a'.  (Not done.  More
>     >> precisely, `?a' in Elisp isn't character syntax but an
>     >> alternative integer syntax.  Note that we could support most of
>     >> the `?a' syntax simply by doing
>     >> 
>     >> (define ?a (char->integer #\a) (define ?b (char->integer #\b)
>     >> 
>     >> and so on.)
>
>     Ken> Only if things aren't quoted.  I think the reader changes
>     Ken> will be needed.
>
> I think you're right overall but I don't see what you mean in detail
> by "if things aren't quoted".  Can you explain?

  (setq y '(?a ?b ?c))
  => (97 98 99)

That won't work if ?a etc are just variable names.

Ken