Re: Emacs rewrite in a maintainable language

[David Kastrup]

address@hidden (Taylan Ulrich "Bayırlı/Kammer") writes:

> "Stephen J. Turnbull" <address@hidden> writes:
>
>> Taylan Ulrich Bayırlı        /Kammer writes:
>>  > I've heard bad things about both defstruct and EIEIO for different
>>  > reasons.  The fact that most Elisp code is shy of using even defstruct
>>  > should tell us something.
>>
>> It does.  It tells us that RMS doesn't like abstract data types.
>> AFAICT there's little inherent problem with defstruct from cl-macs (or
>> cl-lib, I forget which), it's just a matter of style preference
>> (originally rooted in the claim that cl.el was just syntactic sugar so
>> it was a waste of pure space on small machines to require it).
>
> OK, I didn't know of any past ordeals regarding defstruct.
>
>>  > >> an FFI
>>  > >
>>  > > We're getting modules separately.
>>  > 
>>  > I'm not sure if that's comparable to an FFI.
>>
>> Does Guile's FFI refuse to load code if it doesn't call the I-swear-
>> I'm-GPLed function?  That's another requirement for an FFI/module
>> system in Emacs, at least for the present.
>
> Would that really be a blocker if the feature just appears naturally as
> part of the Guile integration?
>
> (The answer to your question is no.  Guile is LGPL anyway.)

A Guile linked into Emacs would of course inherit the GPL of Emacs.  I
don't see its standard dll-loader magically making any loaded module
become part of "software as a whole" with regard to licensing unless it
specifically called Emacs functions.  But as long as the module would
also work with a standalone GUILE interpreter, I don't see the GPL
gaining traction on it.

But of course a tight coupling between Emacs and GUILE _will_ make it
more attractive to write modules with components tieing into editing.

-- 
David Kastrup