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: Wed, 17 Sep 2014 22:34:42 -0400 Message-ID: References: <87wq97i78i.fsf@earlgrey.lan> <87sijqxzr2.fsf@newcastle.ac.uk> <878uliwajb.fsf@taylan.uni.cx> <87lhpitg6t.fsf@fencepost.gnu.org> <87wq92uhwh.fsf@taylan.uni.cx> <541A0E71.6040703@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1411007731 29610 80.91.229.3 (18 Sep 2014 02:35:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 18 Sep 2014 02:35:31 +0000 (UTC) Cc: Taylan Ulrich Bayirli/Kammer , David Kastrup , emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 18 04:35:23 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 1XURZ5-00009u-Ej for ged-emacs-devel@m.gmane.org; Thu, 18 Sep 2014 04:35:23 +0200 Original-Received: from localhost ([::1]:48156 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XURZ4-0003ay-IG for ged-emacs-devel@m.gmane.org; Wed, 17 Sep 2014 22:35:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41308) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XURYm-0003XC-8Z for emacs-devel@gnu.org; Wed, 17 Sep 2014 22:35:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XURYe-0003Qt-Q3 for emacs-devel@gnu.org; Wed, 17 Sep 2014 22:35:04 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:9291) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XURYW-0003QS-Ua; Wed, 17 Sep 2014 22:34:48 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUGAIDvNVNFpZEG/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCwsOJhIUGA0kiAQI0hkXjnoHhDgEqRmBaoNMIQ X-IPAS-Result: ArUGAIDvNVNFpZEG/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCwsOJhIUGA0kiAQI0hkXjnoHhDgEqRmBaoNMIQ X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="90144174" Original-Received: from 69-165-145-6.dsl.teksavvy.com (HELO pastel.home) ([69.165.145.6]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Sep 2014 22:34:43 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id C8B5F60776; Wed, 17 Sep 2014 22:34:42 -0400 (EDT) In-Reply-To: <541A0E71.6040703@dancol.org> (Daniel Colascione's message of "Wed, 17 Sep 2014 15:42:57 -0700") 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:174475 Archived-At: > Imagine the round trip a value might take: There's no translation involved, so no "round-trip" problem. Instead the problem is that there are new kinds of data. These can come from Scheme and look weird from the Elisp side. Basically, Scheme has #f, (), and nil as 3 distinct objects. So Guile-Emacs picked one of those as being Elisp's nil, so as long as you stay all within Elisp things work just fine (presumably), but as soon as some Scheme gets into the picture you might get new values which are similar to nil but aren't `eq' to it. > I'd be happy to use the lower-level portions of Guile for compiling > elisp more efficiently, but I'm adamantly against trying to support both > Scheme and elisp simultaneously. I tend to agree. But I'm not sure it's easy to really stay 100% within Elisp with a Guile-VM. E.g. I suspect some errors signals coming from Guile's runtime will end up using Scheme-style data and will end up spilling into the Elisp side if we're not extra careful. Stefan