From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs rewrite in a maintainable language Date: Sun, 11 Oct 2015 22:53:48 +0300 Message-ID: <83r3l1p4fn.fsf@gnu.org> References: <561A19AB.5060001@cumego.com> <87io6dl0h0.fsf@wanadoo.es> <83vbadp69k.fsf@gnu.org> <87egh1kx83.fsf@wanadoo.es> Reply-To: Eli Zaretskii 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 1444593266 24520 80.91.229.3 (11 Oct 2015 19:54:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 11 Oct 2015 19:54:26 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?iso-8859-1?Q?=D3scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 11 21:54:13 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 1ZlMhA-0002w2-TF for ged-emacs-devel@m.gmane.org; Sun, 11 Oct 2015 21:54:13 +0200 Original-Received: from localhost ([::1]:49570 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlMhA-00068h-9Y for ged-emacs-devel@m.gmane.org; Sun, 11 Oct 2015 15:54:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38580) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlMgi-0005n1-AB for emacs-devel@gnu.org; Sun, 11 Oct 2015 15:53:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZlMgf-0002gX-3U for emacs-devel@gnu.org; Sun, 11 Oct 2015 15:53:44 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:48531) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlMge-0002fZ-SG for emacs-devel@gnu.org; Sun, 11 Oct 2015 15:53:41 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NW200M00N18HI00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Sun, 11 Oct 2015 22:53:39 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NW200MDBN9F1I90@a-mtaout22.012.net.il>; Sun, 11 Oct 2015 22:53:39 +0300 (IDT) In-reply-to: <87egh1kx83.fsf@wanadoo.es> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 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:191265 Archived-At: > From: =D3scar Fuentes > Date: Sun, 11 Oct 2015 21:43:08 +0200 >=20 > Eli Zaretskii writes: >=20 > > It's all a pipe dream, no more, unless someone steps forward who > > really intends and is able to do the job. And that is even before= we > > start talking about which alternative language should that be, > > something that in itself is not a trivial decision. >=20 > I agree, but the key here is that others said "No, there is no need= or > advantage on doing so." Your response is of a very different kind. Not really. I just stopped short of rationalizing why something that is difficult is not really required ;-) > However, it is not absolutely necessary to have a global understand= ing > of the module that it is being translated to the new language. Depe= nding > on the target language, a shallow knowledge can be sufficient. Only where the current code is self-contained, i.e. does not make any serious use of system APIs and is not heavily used by other parts of Emacs. If these conditions are false, then a fairly complete understanding i= s in fact necessary, otherwise we will have gobs of subtle bugs on our hands. Also, depending on the target language, simple 1:1 translation might make no sense, because it could yield insufficient performance. In those cases, the translator will have to reverse-engineer the (largel= y undocumented) requirements from the code, and then reimplement them using more efficient primitives of the target language. That also requires a fairly good understanding of what the code does, and why. And these issues are just the tip of the iceberg.