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 rewrite in a maintainable language Date: Mon, 19 Oct 2015 10:46:47 +0200 Message-ID: <878u6zkzyg.fsf@fencepost.gnu.org> References: <561A19AB.5060001@cumego.com> <876126key3.fsf@gnu.org> <83fv1a6bfu.fsf@gnu.org> <87d1weo7u9.fsf@gnu.org> <83zizi3qr0.fsf@gnu.org> <87lhb1n81y.fsf@gnu.org> <83si594wt3.fsf@gnu.org> <87io64iigs.fsf@gnu.org> <87r3kso1gr.fsf@fencepost.gnu.org> <87wpuks5ek.fsf@T420.taylan> <83vba4i1z3.fsf@gnu.org> <87pp0cqgjf.fsf@T420.taylan> <83twpoi0sp.fsf@gnu.org> <878u70qf75.fsf@T420.taylan> <83mvvghydi.fsf@gnu.org> <5623E3B5.8050407@dancol.org> <87y4f0kos9.fsf@fencepost.gnu.org> <5623EAB2.5000008@dancol.org> <87pp0cotqd.fsf@T420.taylan> <5623F7E2.3010200@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1445244435 26433 80.91.229.3 (19 Oct 2015 08:47:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 Oct 2015 08:47:15 +0000 (UTC) Cc: =?utf-8?Q?Taylan_Ulrich_Bay=C4=B1rl=C4=B1=2FKammer?= , emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 19 10:47:10 2015 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 1Zo661-0008Mq-Mc for ged-emacs-devel@m.gmane.org; Mon, 19 Oct 2015 10:47:09 +0200 Original-Received: from localhost ([::1]:37423 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zo660-0006Q5-Vb for ged-emacs-devel@m.gmane.org; Mon, 19 Oct 2015 04:47:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50786) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zo65w-0006Pz-OK for emacs-devel@gnu.org; Mon, 19 Oct 2015 04:47:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zo65r-00078P-TL for emacs-devel@gnu.org; Mon, 19 Oct 2015 04:47:04 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34020) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zo65g-00077D-Vk; Mon, 19 Oct 2015 04:46:49 -0400 Original-Received: from localhost ([127.0.0.1]:47839 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.82) (envelope-from ) id 1Zo65g-0000JK-7o; Mon, 19 Oct 2015 04:46:48 -0400 Original-Received: by lola (Postfix, from userid 1000) id 8F1D3DF373; Mon, 19 Oct 2015 10:46:47 +0200 (CEST) In-Reply-To: <5623F7E2.3010200@dancol.org> (Daniel Colascione's message of "Sun, 18 Oct 2015 12:49:54 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.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:192051 Archived-At: Daniel Colascione writes: > On 10/18/2015 12:35 PM, Taylan Ulrich Bay=C4=B1rl=C4=B1/Kammer wrote: > >> Guile already supports finalizers (and much, much more) so you >> wouldn't have needed to implement it from scratch for Elisp. :-) > > I'm sure we'll have to extend something sometime. Sure. But general programming facilities are not likely to be it. in spite of Taylan Ulrich's insistence, I am pretty sure that most of the things in need of cross-community work are in the encoding area. I'm also pretty sure that the basic buffer mechanism (basically a string with an insertion point) would warrant a more native reflection in GUILE data structures. >> record types (like an improved defstruct) > > We have EIEIO. And defstruct is fine for most use cases. Over in the > modules discussion, we're talking about letting C modules define > first-class types in elisp. That'd be neat, and defstruct could use the > same machinery instead of a type symbol. > >> CLOS-like OOP > > EIEIO. > >> an FFI > > We're getting modules separately. > >> composable continuations > > We have them already in the form of generators. I don't want > unrestricted call/cc. > >> a module system > > I don't want Guile's. The underlying principle of GUILE's module system is to separate symbols as globally interned strings from the associated variables containing values. Lisp symbols have 4 elements: print name, value cell, function cell, property list. GUILE symbols have the print name, everything else is established separately. That allows for designing arbitrary module systems on top, so it would be feasible to give Elisp its own system. >> hygienic macros > > Unhygienic macros are useful. Nobody will take them from you. > I don't want Guile's opinionated macros. Besides, this point is > out-of-date if Guile supports elisp, since existing elisp macros are > unhygienic. > >> multiple-value returns > > Returning lists works fine, and everyone I know finds CL's multiple > return feature confusing. We can live without it easily, since most > other languages have managed to live without it. > > Besides: we support multiple return values _today_ in the form of > locatives: we call them gv-ref and gv-deref. Well, I'd want to have adopted in order to make the C API more consistent. I'd also want a single static value for the empty string "" (regardless of encoding and r/w state which does not make a difference when there are 0 characters). And so on. Basically, getting any internal changes accepted or even discussed as a GUILE outsider is a rather upstream battle. Of course it doesn't particularly help if you are banned from the developer list... I digress. Apart from the above-mentioned lack of streamlining the no-return-value concepts of the C and Lisp APIs, the multiple-values concept of Scheme is reasonably clear. The programming constructs around it are awkward, but there are by now destructuring forms of "let" that are actually being reasonably nice to use when programming. >> and threads > > Guile by itself sure as hell won't give us threads. You'll have to > solve all the synchronization problems that adding threads will > inflict on the Emacs core. The existing threads branch goes a long way > toward doing that. Sure, but using a thread-supporting underlying programming language means that the Emacs code dealing with multithreading will only have to concern itself with the Emacs-specific synchronization issues rather than mixing this up with the interpreter-specific problems. > I really don't want to shoehorn Guile into Emacs. It's the wrong > runtime for the wrong language being advocated for the wrong reasons. > > I wouldn't mind taking _pieces_ of Guile --- in particular, maybe the > JIT and GC GUILE 2 has no JIT compiler and uses the Boehm GC (and still has not fixed/worked-around/reported the finalizer problem in ) so that's a peculiar choice of things to take. > --- and replacing the existing Emacs implementations of these runtime > facilities, but I don't want Emacs linking against libguile.so, I > don't want users to have to install a separate package, and I don't > want our platform support to be limited by whatever Guile provides. > Basically, I don't want our future in Guile's hands. Well, in a nutshell you don't want the GUILE and Emacs communities to join forces. But that's what the strategic goal is. Your main argument is "we could make do without GUILE". But that's not actually the question. Of course we could. But basically if GUILE is not wanted as an extension language for Emacs, GUILE's intended role as the extension language for GNU is a failure. I think that if the Emacs and GUILE communities can get over their respective "don't you mess with my project" stance and fears that GNU overall would have something to gain. This will require changes in Emacs developer focus and attitudes, and it will require changes in GUILE developer focus and attitudes, and currently there is a sizable number of developers in both camps who would prefer the other camp to drop off the surface of the Earth in order not to complicate matters. I'm not convinced that this is the best way forward. --=20 David Kastrup