emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs rewrite in a maintainable language


From: Taylan Ulrich Bayırlı/Kammer
Subject: Re: Emacs rewrite in a maintainable language
Date: Sun, 18 Oct 2015 19:06:22 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: address@hidden (Taylan Ulrich Bayırlı/Kammer)
>> Date: Sun, 18 Oct 2015 18:37:24 +0200
>> Cc: address@hidden, address@hidden, address@hidden
>> 
>> Eli Zaretskii <address@hidden> writes:
>> 
>> >> From: address@hidden (Taylan Ulrich Bayırlı/Kammer)
>> >> Cc: address@hidden (Ludovic Courtès),  Eli Zaretskii
>> >>  <address@hidden>,  address@hidden
>> >> Date: Sun, 18 Oct 2015 14:54:59 +0200
>> >> 
>> >> Guile's string library is for working with strings (surprise!), not
>> >> arbitrary byte vectors.
>> >> 
>> >> For arbitrary byte vectors, Guile has bytevectors (surprise!!).
>> >
>> > One of the major lessons Emacs development learned since Emacs 20.1 is
>> > that raw bytes happen as part of text (a.k.a. "strings"), and
>> > therefore there's a need to support a mixture of these two in the same
>> > buffer/string.  I think that's something Guile should support as well,
>> > as that will make it a more powerful and flexible extension language,
>> > able to deal with a wider range of real-life situations.
>> 
>> Text as understood by a user of a text editor does not necessarily
>> correspond to strings as understood by a programmer.
>
> It doesn't matter how this data type is called, what's important is
> that it should support both human-readable text and raw bytes in the
> same contiguous stream of "characters".
>
>> Though that doesn't seem to be an absolute requirement for letting
>> libguile compile Elisp, since it can just treat Elisp strings as a
>> separate data type, as GuileEmacs currently does.
>
> That'd be an inconvenience, since it will require a translation layer
> between Emacs strings and Guile strings, and that will hamper
> performance.

I'm not sure in what situations such a translation would be necessary.
I don't think GuileEmacs currently does any such translations.

See e.g. the "can I script Emacs in Scheme already" examples here:
http://www.emacswiki.org/emacs/GuileEmacs

If one passed Elisp strings to a Scheme API or Scheme strings to an
Elisp API there, it would raise an invalid type error.

This is akin to how one cannot interchange C integers with Elisp
integers and all that stuff which one needs to know while working on the
C code of Emacs, except 1. in this case it only applies to strings, and
2. it cleanly raises a type error instead of doing something funny.
(The other day I was hit by this issue while working on Guile's C code,
where I forgot that a scm_blahblah_p predicate will return SCM_FALSE
which is not 0 thus not false in C.  Like Qnil in Emacs.)

Taylan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]