From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: taylanbayirli@gmail.com (Taylan Ulrich =?utf-8?Q?Bay=C4=B1rl=C4=B1?= =?utf-8?Q?=2FKammer?=) Newsgroups: gmane.emacs.devel Subject: Re: Emacs rewrite in a maintainable language Date: Mon, 19 Oct 2015 09:59:20 +0200 Message-ID: <87d1wbp9uv.fsf@T420.taylan> 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 1445241577 6924 80.91.229.3 (19 Oct 2015 07:59:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 Oct 2015 07:59:37 +0000 (UTC) Cc: David Kastrup , emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 19 09:59:32 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 1Zo5Lu-0004HU-86 for ged-emacs-devel@m.gmane.org; Mon, 19 Oct 2015 09:59:30 +0200 Original-Received: from localhost ([::1]:37147 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zo5Lt-0000OP-Gy for ged-emacs-devel@m.gmane.org; Mon, 19 Oct 2015 03:59:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38001) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zo5Lp-0000O5-G2 for emacs-devel@gnu.org; Mon, 19 Oct 2015 03:59:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zo5Lo-0002Qi-6E for emacs-devel@gnu.org; Mon, 19 Oct 2015 03:59:25 -0400 Original-Received: from mail-wi0-x236.google.com ([2a00:1450:400c:c05::236]:36313) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zo5Ln-0002Qa-TU; Mon, 19 Oct 2015 03:59:24 -0400 Original-Received: by wicfx6 with SMTP id fx6so37808014wic.1; Mon, 19 Oct 2015 00:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type:content-transfer-encoding; bh=iOYTp4OngAAnKi8rVNRxv1J/GkqhMUv9xz0RdC50vUU=; b=FyqhYXvBh1v2rx/bz5QnywXFWypa1JjNzKRsYvjfm2PDmw0808Lsa4OqcQd9UOtBEU aHPgaT+9bmthOOqKQNl3Nt2rASTsWRiT9I8XIJ9dxgnMNqpn6Et6lfUTL161N6AhiFf4 dxtUxpABqjZ6fPKSDUFnoanzEnIJHsDNtIyy/Uq1+hDqhwmhXOGoxHo3TN6mxMJ5k916 HTxo8Z4a0GjSuSbtJq4iYRUtmf6gvZiLwBgRUrS4/Y4zg7C1PNlviR2ROqQN6c4tzjSN eAeZrBl7xDXrWn8QPldeJV+Bxlu+OACWJb9Y90EcccdoVcraBlXjpMK5nM53h7h6+bVL g5Ew== X-Received: by 10.180.90.37 with SMTP id bt5mr19172943wib.7.1445241563310; Mon, 19 Oct 2015 00:59:23 -0700 (PDT) Original-Received: from T420.taylan ([2a02:908:c32:4740:221:ccff:fe66:68f0]) by smtp.gmail.com with ESMTPSA id o3sm13894739wif.22.2015.10.19.00.59.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Oct 2015 00:59:21 -0700 (PDT) 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/24.5 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::236 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:192043 Archived-At: Daniel Colascione writes: > 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 implementation >>>>> 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 Emacs >>>> remains a considerable inside job and is not documented on its own. >>>> >>>> So I consider this a strength rather than a weakness of the GuileEmacs >>>> proposition in the long term. >>> >>> I disagree. Integrating the interpreter and the editor makes integrated >>> changes easy. It also makes elisp releases synchronous with Emacs ones. >>> 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 still >>> 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. I think Guile is probably more fertile ground for improvement of language semantics and implementation. >> 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. 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. You say "this and that will fix that" but it's already fixed in Guile. Guile also already supports defining new types in C. >> an FFI > > We're getting modules separately. I'm not sure if that's comparable to an FFI. >> composable continuations > > We have them already in the form of generators. I don't want > unrestricted call/cc. Call/cc is not composable. Composable continuations can implement generators and more, without having the problems of call/cc. >> a module system > > I don't want Guile's. And I do ... but it would be better if we stick to technical points instead of personal preference. :-) >> 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. Guile supports hygienic and unhygienic macros. Hygienic macros are also better called "not broken by default" macros, if we're going to start using slants. ;-) >> 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. MV returns can be very useful (and natural) for some things. Programmers should have the choice to use them. > Besides: we support multiple return values _today_ in the form of > locatives: we call them gv-ref and gv-deref. I don't think that's the same thing. >> 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. > > 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. You want a lot of things and don't want a lot of things but only some of them seem to be backed by concrete reasons instead of personal opinion. I'll now leave this branch of the discussion too because it's probably not going to head in a good direction. I would much rather do something constructive than try counter people's panicky reactions to Guile, whatever reason they have. Taylan