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: Tue, 13 Oct 2015 12:01:50 +0200 Message-ID: <8737xf9je9.fsf@fencepost.gnu.org> References: <561A19AB.5060001@cumego.com> <87io6dl0h0.fsf@wanadoo.es> <87lhb82qxc.fsf@gmail.com> <87oag4jk74.fsf@wanadoo.es> <87k2qrki45.fsf@wanadoo.es> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1444730542 13691 80.91.229.3 (13 Oct 2015 10:02:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 13 Oct 2015 10:02:22 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 13 12:02:20 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 1ZlwPT-0008Sw-MJ for ged-emacs-devel@m.gmane.org; Tue, 13 Oct 2015 12:02:19 +0200 Original-Received: from localhost ([::1]:33429 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlwPT-0004PW-5c for ged-emacs-devel@m.gmane.org; Tue, 13 Oct 2015 06:02:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55134) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlwP3-0004Lm-CF for emacs-devel@gnu.org; Tue, 13 Oct 2015 06:01:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZlwP2-0001Mg-78 for emacs-devel@gnu.org; Tue, 13 Oct 2015 06:01:53 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58825) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlwP2-0001Mc-3y for emacs-devel@gnu.org; Tue, 13 Oct 2015 06:01:52 -0400 Original-Received: from localhost ([127.0.0.1]:44411 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.82) (envelope-from ) id 1ZlwP1-0002k6-L4 for emacs-devel@gnu.org; Tue, 13 Oct 2015 06:01:51 -0400 Original-Received: by lola (Postfix, from userid 1000) id D78DCDF4F8; Tue, 13 Oct 2015 12:01:50 +0200 (CEST) In-Reply-To: (John Wiegley's message of "Mon, 12 Oct 2015 12:39:32 -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:191440 Archived-At: "John Wiegley" writes: >>>>>> =D3scar Fuentes writes: > >>> A subset of Elisp that doesn't have dynamic binding might well produce = code >>> that could be of use to us, > >> That's what I had in mind all the time. We could aim to the subset of El= isp >> that can be translated to a fast enough target code, while remaining >> superior to C in convenience. > >> Or a more radical approach: a Lispy language, easy to learn by those >> who already know Elisp, but which can be translated all the way to >> something as performant as the current C code, while being capable of >> interacting with it. This way, whenever someone needs fast code, he >> would use this other dialect instead of writing C, or the slow Elisp >> (or avoiding the task altogether.) > > If it can leverage what the contributor already knows about Elisp, I'm > all for it. I wonder what RMS' and Eli's reaction would be. Shrug. There is the GUILE branch. In my opinion its largest obstacle towards acceptance is the failure of GUILE strings to offer a comparable feature set to Emacs multibyte strings: nothing outside of the Unicode range, no byte transparent reproduction. This needs an overhaul of GUILE's string handling (which delegates parts of it to helper libraries, some of those being under control of GNU, some not). Another tricky thing is that '() and #f (boolean false) are different entities which Lisp both represents as nil. That will make things somewhat more awkward when writing code for Elisp in Scheme. But the string thing is a performance killer (the branch currently converts back and forth between "Emacs string" and "GUILE string" or possibly byte vectors all the time if I understand correctly). > If they are amenable, would you be willing to prototype it? If we > could see a language description for the subset/alternate, and a > sample compilation into C for some of the functions we have in Emacs > core (that is, reimplementing them as a proof of concept), that would > help sell it. GUILE's byte compiler is supposed to do a better job than Elisp. It's still not native, but the layering of GUILE's compiler might make native code generation more realistic than with Elisp. --=20 David Kastrup