From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Wed, 17 Sep 2014 17:11:46 +0200 Message-ID: <87ppeuth71.fsf@fencepost.gnu.org> References: <87wq97i78i.fsf@earlgrey.lan> <87sijrv6v9.fsf@fencepost.gnu.org> <87ppeux2fi.fsf@netris.org> <87y4titkdl.fsf@fencepost.gnu.org> <87iokmpazn.fsf@yeeloong.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1410966736 26409 80.91.229.3 (17 Sep 2014 15:12:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Sep 2014 15:12:16 +0000 (UTC) Cc: emacs-devel@gnu.org To: Mark H Weaver Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 17 17:12:14 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XUGtr-0000zX-GT for ged-emacs-devel@m.gmane.org; Wed, 17 Sep 2014 17:12:07 +0200 Original-Received: from localhost ([::1]:45584 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUGtr-0006yl-1r for ged-emacs-devel@m.gmane.org; Wed, 17 Sep 2014 11:12:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53141) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUGtc-0006yS-P4 for emacs-devel@gnu.org; Wed, 17 Sep 2014 11:11:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XUGtb-0002yu-39 for emacs-devel@gnu.org; Wed, 17 Sep 2014 11:11:52 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53864) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUGta-0002yT-W4 for emacs-devel@gnu.org; Wed, 17 Sep 2014 11:11:51 -0400 Original-Received: from localhost ([127.0.0.1]:32807 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUGtX-0007RC-98; Wed, 17 Sep 2014 11:11:47 -0400 Original-Received: by lola (Postfix, from userid 1000) id DFF05E05E5; Wed, 17 Sep 2014 17:11:46 +0200 (CEST) In-Reply-To: <87iokmpazn.fsf@yeeloong.lan> (Mark H. Weaver's message of "Wed, 17 Sep 2014 10:39:24 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:174438 Archived-At: Mark H Weaver writes: > David Kastrup writes: > >> mhw@netris.org writes: >> >>> David Kastrup 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