Re: Emacs Lisp's future

[David Kastrup]

Mark H Weaver <address@hidden> writes:

> * I'm not sure that Guile strings should include property lists.

I already mentioned that string ports could be turned into the basic
underlying data representation for Emacs buffers.  That's one case where
it is quite obvious that a string port alone is not a sufficient
representation.

> One can reasonably assume that competent Elisp programmers will keep
> in mind that Elisp strings are more than just characters, but we
> cannot expect that of Scheme programmers, and they've never had any
> tools to deal with it in any case.  Emacs lisp includes procedures
> such as 'substring-no-properties', but Scheme has never had anything
> like that.
>
> Supporting property lists in Scheme raises difficult questions
> such as:
>
>  * What should the Scheme procedures 'string=?' and 'equal?' do when
>    comparing two strings with the equal character sequences but
>    unequal property lists?
>
>  * Should Scheme procedures such as 'substring', 'string-append',
>    'string-upcase', etc, propagate the associated property list
>    data?
>
>  * Are there security implications to carrying around and possibly
>    propagating (via Scheme's "substring") extra information that is
>    effectively invisible to all procedures that have ever been
>    available in Scheme?
>
>  * What should Scheme's 'write' do when applied to a string that
>    includes a property list?  ('write' is analogous to 'prin1').

I should think that GOOPS, the basis for GUILE's builtin object
hierarchy, basically provides all the necessary mechanisms for
transparently making "richer" string variants maintain their additional
data when being manipulated by standard operations.

So while Emacs development would likely benefit from the willingness to
refactor some string internals in a different manner, ultimately the
work of Emacs data implementors should not require tight interaction
with GUILE development.

> While we're on the subject of interoperability between Emacs Lisp and
> Scheme programs, I'm concerned about nil.

[...]

> The problem comes when 'x' originated in Scheme code as (), is later
> copied by Elisp code into something that's conceptually a boolean, and
> then that copy is inspected by Scheme code.  The intent was that the
> copied boolean would be false, but the Scheme code will see () and treat
> it as true.
>
> What do you think?  Do I worry too much? :)

No.  It will be the main recurring interoperation headache.

-- 
David Kastrup