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: Mon, 12 Oct 2015 05:33:56 +0300 Message-ID: <83pp0kq0h7.fsf@gnu.org> References: <561A19AB.5060001@cumego.com> <87io6dl0h0.fsf@wanadoo.es> <83vbadp69k.fsf@gnu.org> <87egh1kx83.fsf@wanadoo.es> <83r3l1p4fn.fsf@gnu.org> <87a8rpkvsu.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 1444617247 28588 80.91.229.3 (12 Oct 2015 02:34:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Oct 2015 02:34:07 +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 Mon Oct 12 04:33:58 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 1ZlSw1-00081H-Q4 for ged-emacs-devel@m.gmane.org; Mon, 12 Oct 2015 04:33:57 +0200 Original-Received: from localhost ([::1]:52195 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlSw0-0003k3-Uw for ged-emacs-devel@m.gmane.org; Sun, 11 Oct 2015 22:33:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58490) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlSvw-0003js-Uh for emacs-devel@gnu.org; Sun, 11 Oct 2015 22:33:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZlSvs-0005Sq-Pr for emacs-devel@gnu.org; Sun, 11 Oct 2015 22:33:52 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:50517) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlSvs-0005Sm-Hp for emacs-devel@gnu.org; Sun, 11 Oct 2015 22:33:48 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NW3006004UWUM00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Mon, 12 Oct 2015 05:33:47 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NW3006LL5SAYO00@a-mtaout20.012.net.il>; Mon, 12 Oct 2015 05:33:47 +0300 (IDT) In-reply-to: <87a8rpkvsu.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.166 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:191297 Archived-At: > From: =D3scar Fuentes > Date: Sun, 11 Oct 2015 22:13:53 +0200 >=20 > Eli Zaretskii writes: >=20 > >> However, it is not absolutely necessary to have a global underst= anding > >> of the module that it is being translated to the new language. D= epending > >> 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 understandi= ng is > > in fact necessary, otherwise we will have gobs of subtle bugs on = our > > hands. >=20 > If the target language is ABI-compatible with C and hence has no > problems calling system APIs, there is no problem with translating = a > function to that language and make it available to the > still-untranslated functions. The calling functions would remain > untouched until they get their turn to be translated. I don't know what you mean by "ABI compatible". If you mean C++, the= n it's a single language (and not the best choice, IMO, as it is not much better for Emacs than C, given its decline and problems of finding people who know it). As soon as you start talking about Java or Python (fully compatible with C, btw), the issues I mentioned star= t piling: you cannot transform the code without understanding what it does. > > Also, depending on the target language, simple 1:1 translation mi= ght > > make no sense, because it could yield insufficient performance. = In > > those cases, the translator will have to reverse-engineer the (la= rgely > > undocumented) requirements from the code, and then reimplement th= em > > using more efficient primitives of the target language. That als= o > > requires a fairly good understanding of what the code does, and w= hy. >=20 > Same as above for the performance and 1:1 translation. Same as above for counter-arguments. > > And these issues are just the tip of the iceberg. >=20 > I have experience doing this type of work (from C++) but the target > language was custom-made for making the process as easy as possible > while being advanced enough to warrant the effort. It was (is) a hu= ge > success. I also have experience (converting a large project from Fortran to C)= . > It would be not so easy with one of the stablished languages (Schem= e, > for instance, has all the problems you mentioned and some more.) I think any language which is "better" (i.e. is known by more programmers) will have the same problems.