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 14:26:38 +0200 Message-ID: <87d1wbniwx.fsf@T420.taylan> References: <561A19AB.5060001@cumego.com> <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> <87d1wbp9uv.fsf@T420.taylan> <22052.51982.9833.353851@turnbull.sk.tsukuba.ac.jp> 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 1445257626 12835 80.91.229.3 (19 Oct 2015 12:27:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 Oct 2015 12:27:06 +0000 (UTC) Cc: Daniel Colascione , David Kastrup , emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 19 14:26:53 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 1Zo9Wd-0002vd-W0 for ged-emacs-devel@m.gmane.org; Mon, 19 Oct 2015 14:26:52 +0200 Original-Received: from localhost ([::1]:38873 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zo9Wd-000432-6r for ged-emacs-devel@m.gmane.org; Mon, 19 Oct 2015 08:26:51 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33233) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zo9WZ-00042v-NL for emacs-devel@gnu.org; Mon, 19 Oct 2015 08:26:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zo9WT-0001l7-LC for emacs-devel@gnu.org; Mon, 19 Oct 2015 08:26:47 -0400 Original-Received: from mail-wi0-x233.google.com ([2a00:1450:400c:c05::233]:33478) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zo9WT-0001kb-BC; Mon, 19 Oct 2015 08:26:41 -0400 Original-Received: by wijp11 with SMTP id p11so3320661wij.0; Mon, 19 Oct 2015 05:26:40 -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=UKqeAiLscUyjJw75mUhnnGWaTsSvnhXgx67mQ/z1iqA=; b=z5GD//QjOaxYM9OLbLKUB5TQ7xVmb9m686xWLliNwRPYUtdMGFBG2Bp1XFZlVahCMe wVs9wWDpx2MFJZrJYN51SWqdgBXJn7ps7RJ8PYnIqL4+CsvvDTV5RlKPJtSe0P7Nn/jn I1acqs85JXhotcCS+vScfEuCCMa3aOaQmo4dD8q46a55xy1Qfij/iesYtUgPbBzoVnXN JOw0tjn7SGAVdVatldqxxwfSnYUUz8V5rNVJp5Is3Mr91KXwq4sDZLixXMlKJX0U/SsC ZEtaLHJ+YbGkcThGMc+yxHoNOriPehRgXhiQJM75TdOa4ifEH+vLHE80dJI6VxniCUrA ulCw== X-Received: by 10.194.144.10 with SMTP id si10mr15536667wjb.49.1445257600756; Mon, 19 Oct 2015 05:26:40 -0700 (PDT) Original-Received: from T420.taylan ([2a02:908:c32:4740:221:ccff:fe66:68f0]) by smtp.gmail.com with ESMTPSA id iw8sm39839780wjb.5.2015.10.19.05.26.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Oct 2015 05:26:40 -0700 (PDT) In-Reply-To: <22052.51982.9833.353851@turnbull.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Mon, 19 Oct 2015 19:50:53 +0900") 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::233 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:192079 Archived-At: "Stephen J. Turnbull" writes: > Taylan Ulrich Bay=C4=B1rl=C4=B1 /Kammer writes: > > 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. > > It does. It tells us that RMS doesn't like abstract data types. > AFAICT there's little inherent problem with defstruct from cl-macs (or > cl-lib, I forget which), it's just a matter of style preference > (originally rooted in the claim that cl.el was just syntactic sugar so > it was a waste of pure space on small machines to require it). OK, I didn't know of any past ordeals regarding defstruct. > > >> an FFI > > > > > > We're getting modules separately. > >=20 > > I'm not sure if that's comparable to an FFI. > > Does Guile's FFI refuse to load code if it doesn't call the I-swear- > I'm-GPLed function? That's another requirement for an FFI/module > system in Emacs, at least for the present. Would that really be a blocker if the feature just appears naturally as part of the Guile integration? (The answer to your question is no. Guile is LGPL anyway.) > > 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. > > I'm not panicking. GuileEmacs has zero attraction for me *personally* > because on the one hand its advocates admit it still needs work. On > the other none of its claimed advantages excite *me* one bit. I didn't have you in mind when I said that. :-) > If we can really rewrite all of Emacs with the exception of device > drivers in Guile, then I'd definitely be excited (I think that's what > Tom Tromey is talking about). But I don't think that effort is likely > to succeed in providing an efficient Emacs at all soon, although it > might provide an efficient Emacs Lisp. So we would end up with three > implementation languages required to understand important (generic) > components of Emacs. Specifically I suppose that redisplay is likely > to remain in C for a long time. I don't think that's a win, > especially with the e^i mental twist required when moving between > Scheme code and Lisp code. I don't think there's any clear plans to rewrite arbitrary or all parts of Emacs's C code in Guile-Scheme. The way I see it, the merge entails broadly 1. letting Guile do all the things it can do better like compiling and running Lisp (regardless of whether it's Guile's C or Scheme code that does so), 2. having the Emacs-specific data types and subroutines in Emacs's C core become libguile data types and libguile procedures, without much change to the body of C code implementing them. AFAIUI, that's precisely what GuileEmacs currently does, and the basic strategy seems to work very well. (It really works as a drop-in replacement, just with bugs.) For instance I can call the Elisp subr `buffer-substring' not only from Elisp code that gets compiled by Guile, I can also import the module `(elisp-functions)' in Scheme (or any other language running on Guile) and have the subr normally found in (symbol-function 'buffer-substring) appear within the Scheme variable `buffer-substring' instead, with Scheme type 'procedure' and all the related privileges of that type. This offers a very nice integration on one hand (only Elisp strings are a separate type from Guile strings), and requires no substantial change to the C code behind many features on the other hand. Actually rewriting parts of that C code in Scheme might be a future endeavor, but I don't think it's a priority. It might be a slow and gradual process for the future, for those parts of the C code for which it makes sense to rewrite in a higher level language. > It doesn't bother me if somebody else wants to do the work, though. Great. :-) I do understand the worry about the additional language that might need to be learned by some Emacs maintainers by the way. That's one of the actually sensible criticisms I've heard against GuileEmacs. There's probably no real solution to that, but I think it will be the correct trade-off. Scheme is more similar to than different from Elisp, and Guile is gaining a huge amount of importance via Guix, and has also otherwise become a really great general-purpose programming language. It will most likely play a very important role in the future of GNU, so I would say GNU hackers should look forward to learning it. With Guix you have Lisp in your initramfs, Lisp running your init system and service management, Lisp driving your package manager, your package recipes are Lisp expressions evaluating to Lisp objects, and so on and so forth. That Lisp is normally Guile Scheme, but if Emacs runs seamlessly as part of Guile... This is not a pipe dream. Guix is working on the 0.9 release with very steady progress, and GuileEmacs just needs some love. Taylan