From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Emacs rewrite in a maintainable language Date: Sun, 18 Oct 2015 12:49:54 -0700 Message-ID: <5623F7E2.3010200@dancol.org> References: <561A19AB.5060001@cumego.com> <87r3kusx8z.fsf@fencepost.gnu.org> <83lhb26eb9.fsf@gnu.org> <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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="E5pm77s6W1UUHBOJrAGhi7Sn578TW8kJg" X-Trace: ger.gmane.org 1445197833 8261 80.91.229.3 (18 Oct 2015 19:50:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 18 Oct 2015 19:50:33 +0000 (UTC) Cc: David Kastrup , emacs-devel@gnu.org To: =?UTF-8?Q?Taylan_Ulrich_Bay=c4=b1rl=c4=b1/Kammer?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 18 21:50:23 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 1ZntyJ-0004DD-3y for ged-emacs-devel@m.gmane.org; Sun, 18 Oct 2015 21:50:23 +0200 Original-Received: from localhost ([::1]:35375 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZntyI-0003Ye-GG for ged-emacs-devel@m.gmane.org; Sun, 18 Oct 2015 15:50:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53000) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Znty1-0003XR-KN for emacs-devel@gnu.org; Sun, 18 Oct 2015 15:50:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zntxy-0001TO-Ds for emacs-devel@gnu.org; Sun, 18 Oct 2015 15:50:05 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:52580) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zntxx-0001St-Ku; Sun, 18 Oct 2015 15:50:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=J0Oqcn88coXA9/6nocOgDZv1oLYMozY+2zOm/D6I6Ew=; b=meYn2GJA+jC+QtL3oYHOAinq1iZRZkumu7WumabrXm4Q7PPn+Dtyi07pKLWLf5ynYCqZodIbToccW2Q+Er2iO6QiwAIEDViSiDlsTrfxSlgh6UrkBu+5Ydvh61VQNqqA+bxs0ikABSA/oWGyjqnUXyXDvKOLigUMWe1V6ClSdMQFZ/EancmVdHZQhBMiRdrz256GY5aK3bJ+ePpjwMrwHLbDl7sBGT38s+fdLbq/4CyWzs6sWhvKbxj64Mru6mPur9BUX52R33Ix5ntkLTJ/1cLm2f5ajtfne+2xCIcmUM4FpsWvmg66K/Qb8DWUIssQ8DfYHmlpXwMtonNiq8RSzQ==; Original-Received: from c-24-16-208-239.hsd1.wa.comcast.net ([24.16.208.239] helo=[192.168.1.210]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1Zntxw-0001zC-D6; Sun, 18 Oct 2015 12:50:00 -0700 X-Enigmail-Draft-Status: N1110 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: <87pp0cotqd.fsf@T420.taylan> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:192010 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --E5pm77s6W1UUHBOJrAGhi7Sn578TW8kJg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/18/2015 12:35 PM, Taylan Ulrich Bay=C4=B1rl=C4=B1/Kammer wrote: > Daniel Colascione writes: >=20 >> On 10/18/2015 11:35 AM, David Kastrup wrote: >>> Daniel Colascione writes: >>>> Wanting to use one language is, IMHO, a poor choice for wanting to >>>> completely swap out a language. I am opposed to Guilemacs, not only = on >>>> technical grounds, but also because elisp is essential to Emacs (and= >>>> not just an optional extension system), and I want its implementatio= n >>>> to live alongside the rest of the Emacs core code. >>> >>> I'm not convinced that it's a bad idea to separate the Elisp >>> implementation more from the Emacs core code. It provides a >>> well-documented interface between the two: hacking the C code in Emac= s >>> remains a considerable inside job and is not documented on its own. >>> >>> So I consider this a strength rather than a weakness of the GuileEmac= s >>> proposition in the long term. >> >> I disagree. Integrating the interpreter and the editor makes integrate= d >> changes easy. It also makes elisp releases synchronous with Emacs ones= =2E >> I don't think a strong library separate here gives us anything useful.= >> >> Consider my recent change to add finalizers to elisp. I saw a need for= >> the feature and just implemented it directly in Emacs. What would the >> equivalent be in a guilemacs world? I'd have had to make the change >> upstream in guile (where I suspect the process is much more involved),= >> wait for a stable release of guile, added Emacs support, and then stil= l >> not have been able to rely on the feature until Emacs dropped support >> for the last version of Guile to lack the feature. >> >> We'd have to go to all that trouble for what, exactly? A cleaner >> internal API? I don't buy it. Guilemacs has other disadvantages: >> currently, Emacs supports _only_ elisp as a first-class extension >> language. Guilemacs would invite people to write Emacs extensions in >> Scheme, JavaScript, and whatever else Guile ends up supporting, which >> will create fragmentation. A unified elisp ecosystem is a strength. >=20 > 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. > 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. > hygienic macros Unhygienic macros are useful. 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. > 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= =2E 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 --- 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. More broadly, I don't think the Emacs lisp implementation is anywhere close to being a priority. It's adequate for now, especially given that we have lexical binding and real closures. The IDE-like features we're missing are much more important. --E5pm77s6W1UUHBOJrAGhi7Sn578TW8kJg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJWI/fiAAoJEN4WImmbpWBls80P/j/sybhms5SkLR3+05ZpASgT RuDEvsHpQhuhtcjcll3wf2S7Acuz3eomolEwpkXpWvEe9pk3ErmiKDv+53VR6Nle k3yMCaxS5ebFQIIO7B3HZzsxG3L5ZCQWxA8ybKsoWK/GcaCwASwl1UXjQwvXZNXg WsLIwKftz46cNs74ZqAm/W00IQ6m+V+y174BlCADbcQOhfl9fsfrhKjbPB1jf/Bb 66APlJabAJimC42DOdoMkNtcOzFdf4ie3tsT5qQ6VzA5tA6e/OQm75Z2U9Hf3GEl Bq+COIpS9hMbvV9lNrisYWrxs1nRszRz3FEkhG0JVajn97bJuKpj+lAtgJLjFLpT BE6b/EfIFlTjGy8wxOdb8SFgyfmxCDO2js6kbjhO4DM/TqKuPwmHH6GkZGQAY0eA mKmUSNCcnc58RTBL5bXkvXhqskn1Ci4mRjDWZolqTG7+RQfHOHqq8WmEl5/OhkWk Jz1WIHADegsUhKClqcsqACekVv4tYon1hz7Hpzs0TTESQXJQhunDq3qbMTu9ndY2 syGU0co6Sald+LjXwvkgH6IJ0qJSJ5SicR1b2MYwBEm0CXJ56EJiaCXmfVPWhP0M P5llsX4/w4sOJOO7QNv+ZY2BE461IXh6fta/WiLR1adxNqmPiks3UJnHctg6Oact wtEw3bRrzdulzvn7gVCo =bQvG -----END PGP SIGNATURE----- --E5pm77s6W1UUHBOJrAGhi7Sn578TW8kJg--