Re: Emacs rewrite in a maintainable language

[David Kastrup]

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.

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

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.

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

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

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

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

-- 
David Kastrup