Re: Emacs rewrite in a maintainable language

[taylanbayirli@gmail.com (Taylan Ulrich Bayırlı/Kammer)]

David Kastrup <dak@gnu.org> writes:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Eli Zaretskii <eliz@gnu.org> skribis:
>>
>>> Guile's i18n is today where Emacs was at v20.1, with the (important)
>>> difference that its internal representation is based on Unicode and
>>> UTF-8.
>>
>> This is incorrect.
>>
>>> The lessons of Emacs development since then till today are yet to be
>>> learned and incorporated into Guile.
>>
>> Probably many of them, but maybe not all.  After all, Guile is not a
>> text editor, so the requirements may be different.
>
> 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.)

Guile's string library is for working with strings (surprise!), not
arbitrary byte vectors.

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.

I'm pretty sure that nearly every programming language with a sane
string library does more or less the same thing.  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.


For some fun that can result from functions with ill-defined domains,
see the shell-quasiquote thread.  Yay for code injection!

Taylan