Re: guilev1/2 musing

[David Kastrup]

Thomas Morley <address@hidden> writes:

> In other posts you wrote about the possibility we could fork guilev1.
> Do you see any way to implement full Unicode support in such a fork of
> our own and in a saner way than current guilev2?

If we had that amount of manpower, that work would likely be better
implemented in fixing Guile2.  Emacs revolves all around characters and
strings and buffers (which are basically random access string ports) and
it took at least 5 years to clean up a basically working multibyte
implementation that was forcefed to Emacs by decree to the degree where
it was competitive.  RMS in the end was right: this headstart was needed
for Emacs to get where it is now but it was a painful process.

Emacs addresses UTF-8-like encoded strings (there are special sequences
for raw bytes and character codes beyond Unicode, but the basic scheme
is UTF-8) by character, and UTF-8-like encoded buffers by character, and
that comes at a cost (though considerably mitigated) that the Scheme
standard does not really care for, and the Guile programmers, most of
all Andy Wingo, very much consider the Scheme standard a holy grail.  So
UTF-8 based internals are not likely to get a lot of sympathy.

> From my point of view (and limited knowledge) other newly implemented
> guilev2-procedures are not _that_ important.

The compiler could have potential but LilyPond's program/data/language
model has rather limited means of making use of it.  But even while it
would not likely help a lot for user-level programming, more things
could be programmed in .scm files rather than C++ without the same
performance impact we have now for doing things in Scheme.

There are also numerous bug fixes, of course.

-- 
David Kastrup