From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Sat, 27 Sep 2014 13:23:10 -0400 Message-ID: References: <54193A70.9020901@member.fsf.org> <87lhp6h4zb.fsf@panthera.terpri.org> <87k34qo4c1.fsf@fencepost.gnu.org> <54257C22.2000806@yandex.ru> <83iokato6x.fsf@gnu.org> <87wq8pwjen.fsf@uwakimon.sk.tsukuba.ac.jp> <837g0ptnlj.fsf@gnu.org> <87r3yxwdr6.fsf@uwakimon.sk.tsukuba.ac.jp> <87tx3tmi3t.fsf@fencepost.gnu.org> <834mvttgsf.fsf@gnu.org> <87lhp5m99w.fsf@fencepost.gnu.org> <87h9ztm5oa.fsf@fencepost.gnu.org> <87d2ahm3nw.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1411838640 16405 80.91.229.3 (27 Sep 2014 17:24:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 27 Sep 2014 17:24:00 +0000 (UTC) Cc: handa@gnu.org, Eli Zaretskii , dmantipov@yandex.ru, stephen@xemacs.org, emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 27 19:23:52 2014 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 1XXvio-0000FR-W3 for ged-emacs-devel@m.gmane.org; Sat, 27 Sep 2014 19:23:51 +0200 Original-Received: from localhost ([::1]:56608 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXvio-0008Kt-Gt for ged-emacs-devel@m.gmane.org; Sat, 27 Sep 2014 13:23:50 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43848) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXvie-0008Ki-Ph for emacs-devel@gnu.org; Sat, 27 Sep 2014 13:23:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XXviX-0001Sh-A5 for emacs-devel@gnu.org; Sat, 27 Sep 2014 13:23:40 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:43701) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXviH-0001HU-7Q; Sat, 27 Sep 2014 13:23:17 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUGAIDvNVNFxKjo/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCwsOJhIUGA0kiAQI0hkXjnoHhDgElGKUN4Fqg0wh X-IPAS-Result: ArUGAIDvNVNFxKjo/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCwsOJhIUGA0kiAQI0hkXjnoHhDgElGKUN4Fqg0wh X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="91043414" Original-Received: from 69-196-168-232.dsl.teksavvy.com (HELO pastel.home) ([69.196.168.232]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Sep 2014 13:23:10 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 89AA67ABB; Sat, 27 Sep 2014 13:23:10 -0400 (EDT) In-Reply-To: <87d2ahm3nw.fsf@fencepost.gnu.org> (David Kastrup's message of "Sat, 27 Sep 2014 18:25:23 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:174750 Archived-At: > I don't think that having to retain a separate implementation of strings > in Emacs makes much sense in the course of integrating GUILE and Emacs. There's integration and integration. Currently Guile-Emacs is about replacing the GC and byte-code interpreter of Emacs with Guile's. Most of the actual primitives used are Emacs's own, AFAIK (with some exceptions, such as the things that touch cons cells and numbers, IIUC). I'm not really interested in spending time improving Guile. The goal of Guile-Emacs (from Emacs's point of view) is to use some pre-existing VM so as to avoid spending time on Emacs's own. So if we can't make use of Guile's strings because they're not good enough, then we won't use them. Of course, maybe we'll have to manipulate Guile's strings in order to use Guile's FFI or some Scheme library. If/when that becomes a performance problem, we'll see what needs to be done about that. Until then: it's not like this is a problem we need to fix now (if ever). -- Stefan