From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: John Wiegley Newsgroups: gmane.emacs.devel Subject: Re: Emacs rewrite in a maintainable language Date: Tue, 13 Oct 2015 09:22:37 -0700 Organization: New Artisans LLC Message-ID: References: <561A19AB.5060001@cumego.com> <87io6dl0h0.fsf@wanadoo.es> <87lhb82qxc.fsf@gmail.com> <87oag4jk74.fsf@wanadoo.es> <87k2qrki45.fsf@wanadoo.es> <83mvvnooo4.fsf@gnu.org> <83lhb7oo4e.fsf@gnu.org> <83k2qqzuir.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1444753436 19356 80.91.229.3 (13 Oct 2015 16:23:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 13 Oct 2015 16:23:56 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 13 18:23:51 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 1Zm2Me-0007iy-6G for ged-emacs-devel@m.gmane.org; Tue, 13 Oct 2015 18:23:48 +0200 Original-Received: from localhost ([::1]:37286 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zm2Md-0006BP-GS for ged-emacs-devel@m.gmane.org; Tue, 13 Oct 2015 12:23:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38074) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zm2Lh-00058A-N7 for emacs-devel@gnu.org; Tue, 13 Oct 2015 12:22:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zm2Lb-0008L9-Kg for emacs-devel@gnu.org; Tue, 13 Oct 2015 12:22:49 -0400 Original-Received: from mail-pa0-x234.google.com ([2607:f8b0:400e:c03::234]:35171) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zm2Lb-0008Kk-Fh for emacs-devel@gnu.org; Tue, 13 Oct 2015 12:22:43 -0400 Original-Received: by pabve7 with SMTP id ve7so25990861pab.2 for ; Tue, 13 Oct 2015 09:22:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:subject:in-reply-to:date:organization:message-id :references:user-agent:mail-followup-to:mime-version:content-type; bh=KP9clrJpj9mReUUwD09T5y41buU6MqzINo0eiADDN+o=; b=H5VMDuJQ3Bt1zkLIe91QvhF83LvJYXH1c+ebxzvjmZOnE2REqsjuAWs0anfL7yWphb kWfcCfc6/nVJdxbPIQP4CaY1KdE37aiNnDwjqmCu22POraR/y668sF11yV3NDjgHmhld rTw9Xk1HaHLydQtTCXb64hxbiCfWwqX7LZMx3t/gBsjcWQqFxtWUNGrntFwYGnDlo03+ yZopqcz97/t3cxsR7SWY6gpBBZ24Kwsx7Jp9EzajJ9FP8bJoIu5Z8SOgEs8ZujujyP9W OVUNptBt/VW/Gx4OpJOXylKstd4H1YaK4bALhyc1P8HxlCMPGHc46HyXKNJI4B4Im8p8 fEEA== X-Received: by 10.68.243.37 with SMTP id wv5mr40733993pbc.68.1444753362590; Tue, 13 Oct 2015 09:22:42 -0700 (PDT) Original-Received: from Vulcan.local (76-234-68-79.lightspeed.frokca.sbcglobal.net. [76.234.68.79]) by smtp.gmail.com with ESMTPSA id so4sm4716605pbc.72.2015.10.13.09.22.41 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 13 Oct 2015 09:22:41 -0700 (PDT) Original-Received: by Vulcan.local (Postfix, from userid 501) id DE944F2DB0C2; Tue, 13 Oct 2015 09:22:40 -0700 (PDT) In-Reply-To: <83k2qqzuir.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 13 Oct 2015 17:57:00 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (darwin) Mail-Followup-To: emacs-devel@gnu.org X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c03::234 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:191493 Archived-At: >>>>> Eli Zaretskii writes: >> > On second thought, I don't think I understand the idea at all. What does it >> > mean "a Lispy language, easy to learn"? Is it a Lisp dialect, or is it C >> > with a set of Lisp-like macros preprocessed into C? What exactly are the C >> > aspects that we are trying to save the programmer from? And which part(s) of >> > the core do we expect to be able to rewrite in this "Lispy" language? > Can we please see a couple of examples, as a kind of concept demonstration, > just to feel the taste of this? For example, how would you write make_frame > in this language? (This would be an example of creating a Lisp object which > is backed up by a large C struct that has members not visible from Lisp.) > Will we have some kind of 'defstruct' in this "subset"? How will we > distinguish Lisp objects from C objects? > > Also, please try to answer the other questions I asked above. I think they > are important for us to understand what exactly is being proposed and what > do we try to accomplish. I'd like to heartily second these requests from Eli, as I wonder the same things. > If this means we will have C code written in Lisp syntax, then are you > saying the syntax of C is the main difficulty for understanding the C core > code? E.g., let's imagine that we rewrote the display engine this "Lispy" > language -- do we really believe it will be easier to understand and > maintain? Not the syntax of C itself, but the macros and tests that happen within that C code. The Lispy language *should* be more transparent as to the intent of the function. But as you say, we need to see real examples of this before anyone should believe that. > Or what about regex.c -- are we going to "lispify" that? I don't know how much C we should get rid of, actually. At the very least, we'd need C to bootstrap the Lispy compiler, for portability. > So we will have a mixture of C and Lisp, or C blocks within Lisp code? How > will that help readability and maintainability? I think the idea was just to shrink the surface area of the C code, and get closer and closer to "everything in Lisp". But as you say, we'd need to see some experiments first. The C we have works for us, so this idea is pretty low priority. As you wrote in another thread, there are several, higher priority items that would win us more contributors faster (documentation, etc). Even changing from C to a Lisp would not be a silver bullet: the display code would still be a hard problem to solve. John