Re: Emacs Lisp's future

[David Kastrup]

Mark H Weaver <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>> address@hidden writes:
>>
>>> David Kastrup <address@hidden> writes:
>>>
>>>> That's not all that much manpower.  If you take a look at the commits in
>>>> the master branch that are not merges from the stable branch, I think
>>>> that more than 90% are from Andy Wingo.
>>>
>>> That's an interesting way to pretend that Ludovic and I don't exist, by
>>> excluding merges.
>>
>> Work on the stable branch is supposedly maintenance rather than
>> forward-looking development.
>>
>> It's actually a good sign for a project's stability if more people work
>> on maintenance than on new things.  But I was commenting on the amount
>> of manpower getting work done on new things.
>
> Plenty of "new things" have been added to the stable-2.0 branch.
> Just read the NEWS file for 2.0.
>
>   
> http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob_plain;f=NEWS;hb=stable-2.0

That also lists plenty of things that have been _removed_ during the
stable-2.0 branch, breaking existing uses of it:

    Making the vector interface operate only on a single representation will
    allow future versions of Guile to compile loops involving vectors to
    more efficient native code.

    ** 'htons', 'htonl', 'ntohs', 'ntohl'

    These procedures, like their C counterpart, were used to convert numbers
    to/from network byte order, typically in conjunction with the
    now-deprecated uniform vector API.

    This functionality is now covered by the bytevector and binary I/O APIs.
    See "Interpreting Bytevector Contents as Integers" in the manual.

    ** 'gc-live-object-stats'

    It hasn't worked in the whole 2.0 series.  There is no replacement,
    unfortunately.

    ** 'scm_c_program_source'

    This internal VM function was not meant to be public.  Use
    'scm_procedure_source' instead.


For me personally, LilyPond's ongoing efforts to port to GUILE-2.0 have
been bitten by

    ** `define-public' is no a longer curried definition by default

    The (ice-9 curried-definitions) should be used for such uses.  See the
    manual for details.

It's noteworthy that the replacement (ice-9 curried-definitions) is not
working correctly in the current version of GUILE distributed in Ubuntu
and there are in fact _still_ broken functions in current stable-2.0.

Making a "stable" branch a moving target where functionality gets
removed leads to situations where code linking libguile dynamically
stops working.

That kind of policy would likely also end up to be problematic for
Emacs.

>>> Why should our contributions be excluded just because they start out
>>> on the stable-2.0 branch and later flow to master by way of merges?
>>
>> Would you claim that the stable-2.0 branch is where new developments
>> are generally done?  That would seem like a somewhat unusual
>> development model.
>
> Yes, it's unusual, but whenever possible we add new modules and other
> features to the stable-2.0 branch, so that users of 2.0 will benefit
> from them.  The exceptions are:
>
> * Work related to the new compiler/VM, which have changed substantially
>   on the master branch.
>
> * Disruptive changes that carry a significant risk of adding new bugs.
>
> * Changes that would break API or ABI compatibility.

Like removing functionality or moving it to separate modules?

At the current point of time, GUILE is a project that is mostly catering
for itself, so breaking its own rules whenever it is convenient affects
a limited circle outside of GUILE.  If GUILE wants to posit itself as
basic infrastructure for the GNU project, this setup is going to lead to
more problems than it does now.

-- 
David Kastrup