Re: Emacs rewrite in a maintainable language

[Taylan Ulrich Bayırlı/Kammer]

David Kastrup <address@hidden> writes:

> address@hidden (Taylan Ulrich "Bayırlı/Kammer") writes:
>
>> David Kastrup <address@hidden> writes:
>>
>>> I quote from the GUILE project page:
>>>
>>>     What is Guile? What can it do for you?
>>>
>>>     Guile is the GNU Ubiquitous Intelligent Language for Extensions, the
>>>     official extension language for the GNU operating system.
>>>
>>>     Guile is a library designed to help programmers create flexible
>>>     applications. Using Guile in an application allows the application's
>>>     functionality to be extended by users or other programmers with
>>>     plug-ins, modules, or scripts. Guile provides what might be
>>>     described as "practical software freedom," making it possible for
>>>     users to customize an application to meet their needs without
>>>     digging into the application's internals.
>>>
>>> I don't see a qualifier "unless you were planning to write a text
>>> editor".  GUILE even has "Extensions" in its name.  As well as
>>> "Ubiquitous".  So how do you reckon that it should not be used for
>>> extending text editors?  And how do you plead at the same time that it
>>> should be used for extending Emacs?
>>>
>>> It's not just for the sake of GuileEmacs that GUILE needs to work on the
>>> cost of passing even mere UTF-8 into GUILE and back out.  GUILE cannot
>>> even pass its own strings through its own string ports without
>>> converting back and forth.
>>
>> The state of the world of software would be even more horrible than it
>> is now if every program tried to accommodate for every possible
>> invalid input with something other than gracefully aborting.  (Many
>> abort ungracefully, sadly.)
>
> 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.

>> Guile's string library is for working with strings (surprise!), not
>> arbitrary byte vectors.
>
> 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.

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.  During the transition from Guile 1.x
to 2.x, that sadly meant breaking some backwards compatibility, because
some abstractions in Guile 1 were not good enough.

> 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.

GuileEmacs will most likely benefit significantly from further versions
in the 2.x series.  I seem to recall it hitting limitations in 2.0 that
were then put in prospect to be fixed in future versions.

>> 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.

>> I'm pretty sure that nearly every programming language with a sane
>> string library does more or less the same thing.
>
> Even Emacs has unibyte strings.  But it does not refuse using string
> operators on them.  GUILE bytevectors don't offer substrings and other
> basic operations.

Bytevectors aren't strings.  I did not miss "substring" even while
implementing e.g. <https://github.com/TaylanUB/scheme-bytestructures>.
You can use bytevectors for a variety of things; if you want to use them
for a "maybe badly encoded string" data type, you'll need to build such
an abstraction.

>> This is not a problem of Guile; it's a fundamental problem of the
>> requirement to allow working with byte vectors that "ideally are but
>> are not necessarily" strings.  Offering a data type encapsulating that
>> idea that falls between byte vectors and strings is a very special
>> case and it should not be surprising that a general-purpose
>> programming language doesn't provide such a data type by default.
>
> 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...

I would rather say that being an extension language means you can
integrate your own data types and subroutines easily with the language,
and the fact that GuileEmacs trivially just uses Elisp's existing string
data type and subroutines shows us that Guile fulfills that perfectly
well.

>> For some fun that can result from functions with ill-defined domains,
>> see the shell-quasiquote thread.  Yay for code injection!
>
> It's more like "yay for culture difference".  You prefer functions being
> useful for fewer cases while touting that as an advantage.

If with "being useful for fewer cases" you really mean "not being
vulnerable to code injection by clearly defining the domain of the
function" then yes, I very much tout that as an advantage.

> 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.


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.

Taylan