Re: Emacs rewrite in a maintainable language

[David Kastrup]

address@hidden (Taylan Ulrich "Bayırlı/Kammer") writes:

> David Kastrup <address@hidden> writes:
>
>> address@hidden (Taylan Ulrich "Bayırlı/Kammer") writes:
>>
>>> David Kastrup <address@hidden> writes:
>>
>> It is not the job of an extension language to dictate application
>> behavior.
>
> It is the job of programming tools to aid programmers in writing good
> applications.

As long as you call Emacs a bad application because of its support of a
large number of encodings and situations beyond Unicode and utf-8,
support that was driven by user requirements and has been a long series
of improvements, you are not on a good road to sell GuileEmacs to either
Emacs or GUILE developers.

>> It is not the job of an extension language to dictate the concept of
>> "character".  Of course, not everything can be supported out of the
>> box and there are limits to what can be supported due to technical
>> reasons.  However, the stance of the GUILE developers is to stop
>> people using GUILE from doing things they consider not their problem.
>
> What is a character and what is a string is understood very well, and
> Guile provides clean abstractions for these, as any sane general
> purpose language should.

GUILE does not provide an "abstraction" but rather is Unicode-only to a
degree where (integer->char #xD800) produces an error, making it even
impossible to manipulate CESU-8 strings.

> While I can't speak for the Guile developers, I can assure you that
> their stance is to provide the best possible abstractions a general
> purpose language should provide.

Again: if GUILE is no longer considered an extension language, this
needs to be communicated to GNU in order to adapt its intended and
advertised role in the GNU project.

>> This stance, possibly partly due to only a single developer working
>> in isolation on the "unstable" branch and everybody else confined to
>> changes in the "stable" branch, is going to end a roadblock for
>> projects like GuileEmacs.
>
> You seem to be making wrong assumptions about Guile's development
> model.  I don't think the fact that the upcoming 2.2 has been mostly a
> one person project has much to do with the incompatibilities between
> 1.x and 2.x.

That's not what I said.  What I said is that work on the encoding
problems of GUILE (and having to do conversions for passing a
GUILE-internal string through a GUILE-internal string port is a problem)
has no place since the "unstable branch" contains just single-person
compiler-focused work while such changes in a "stable branch" would be
uncalled for.  This setup leads to a strong defensive stance preferring
the status quo since there is no place for most changes that are not
mere bugfixes or incremental improvements to go to.

>>> For arbitrary byte vectors, Guile has bytevectors (surprise!!).
>>>
>>> If one implemented a text editor from scratch in Guile and wanted to
>>> allow editing files with no proper encoding, one would use an
>>> abstraction on top of bytevectors.
>>
>> It is not the job of an extension language to dictate what
>> constitutes "proper encoding".  It is the job of the application.
>
> Yes, it *is* the job of a string library to offer abstractions for
> well-defined encodings of strings.

Shrug.  "abstraction" is not the same as "restriction".  Unicode is not
an abstraction.  It's a reference point for an implementation.  And as a
reference it was good and versatile enough that Emacs changed its
multibyte implementation in Emacs 23 to one based on UTF-8 and Unicode
internally.  And because Emacs multibyte encodings were rather
well-abstracted at the application layer, this change, while extensive
and pervasive, was surprisingly non-disruptive for applications.

>> GUILE is first and foremost an extension language.  That is how it
>> advertises itself on its web page.  That it supports the
>> general-purpose programming language Scheme is a boon and
>> implementation choice.
>>
>> If GUILE developers insist on GUILE being foremost a general-purpose
>> programming language rather than an extension language, they should
>> notify the GNU project and change their web page.  There is no point
>> in GNU promoting GUILE as an extension language if the GUILE
>> developers are no longer on board with that target.
>
> You seem to be making a strange distinction between a general-purpose
> and an extension language and implying that an "extension language"
> should fill exactly the use-cases of Emacs for some reason...

Not just Emacs.  Pretty much every application that requires more
specific error handling than rejecting an entire file or communication.
Like, say, LilyPond.

>> That is a pretty alien concept to established Emacs developers, Emacs
>> being the proverbial glue and shoe string across dozens of different
>> platforms right from the beginning of GNU where POSIX would have been
>> luxury.
>
> Maybe some established Emacs developers should get with the times
> then.

Shrug.  Files won't magically convert themselves into only containing
material encodable by proper UTF-8 and nothing else.  Dropping
everything achieved in character and string handling since Emacs 20 so
that GUILE must not adapt is not an option that is realistic.

> I'm not interested in continuing this discussion because it's just as
> unproductive as the last time.  GuileEmacs has come *very* far, and
> most arguments I hear against it seem based in apocalyptic FUD, and in
> particular spitefulness due to past negative experiences with the
> Guile 1.x/2.x transition, which has really nothing to do with
> GuileEmacs, a Guile 2.x project.  That is not to say it's going to be
> fairies and pixies.  There's significant work to be done on it and I
> hope I will find some time to contribute to it in the not too distant
> future.

You'll not be able to restrict all changes to Emacs (GuileEmacs being a
branch of Emacs development).  There are changes and improvements
necessary in GUILE itself to make it viable as a platform for running
Emacs on.  Denying that is doing a disfavor to those who have invested
considerable work into GuileEmacs by now since it makes it less than
more likely that GuileEmacs can sensibly become the main implementation
of Emacs.

-- 
David Kastrup