From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Wed, 17 Sep 2014 15:42:57 -0700 Message-ID: <541A0E71.6040703@dancol.org> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="h1N3Nqn5oFXNr5Ha9WnLS5PbXme5sqr01" X-Trace: ger.gmane.org 1410993820 3044 80.91.229.3 (17 Sep 2014 22:43:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Sep 2014 22:43:40 +0000 (UTC) Cc: emacs-devel@gnu.org To: Taylan Ulrich Bayirli/Kammer , David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 18 00:43:34 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 1XUNwd-00011f-TQ for ged-emacs-devel@m.gmane.org; Thu, 18 Sep 2014 00:43:28 +0200 Original-Received: from localhost ([::1]:47563 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUNwd-0005gN-Du for ged-emacs-devel@m.gmane.org; Wed, 17 Sep 2014 18:43:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36406) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUNwZ-0005df-53 for emacs-devel@gnu.org; Wed, 17 Sep 2014 18:43:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XUNwS-00041E-VF for emacs-devel@gnu.org; Wed, 17 Sep 2014 18:43:23 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:59240) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUNwS-0003zF-KI for emacs-devel@gnu.org; Wed, 17 Sep 2014 18:43:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=6GYbaDoEvHkJDoDblOXd/HTUJgrnJUaY5iuxiBuIRLs=; b=aM3wys6ugnEy4LcuzFlnClL4tHLPyy/gFbgMVB96ciSuPKWomlkEKzweVfUUSzLJOZK6MczJPnIY7HAeEB6I7zJcUffoUSROz18M8pcove8CaeH0AFmbB1HHfP9ANI0c5XBayfsYUQkx0i+4z+EKBtrW4MNgYirjyD2ienqnyQn/74oH+39q3KXCFTX+IMaIBlNIIt2uRIQKRMmUShc5qG1Ula5GXaSGY0Dr1+z6rQAaT2Gid2zQUsAeSCCnGQk9Bsw82cZTBb8JD/VN2E7KMn9DAh3uOb6hrGiPah06w4rjtdO0PMoxoU3g+ceV4P/3OI5KCOmF1gX9dbd9AJ9naA==; Original-Received: from [2620:10d:c083:1003:863a:4bff:fec8:e538] by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_RC2) (envelope-from ) id 1XUNwF-0004iB-5H; Wed, 17 Sep 2014 15:43:03 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 In-Reply-To: <87wq92uhwh.fsf@taylan.uni.cx> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:174470 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --h1N3Nqn5oFXNr5Ha9WnLS5PbXme5sqr01 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 09/17/2014 01:11 PM, Taylan Ulrich Bayirli/Kammer wrote: > Actually, this is just a special-case of the first point, regarding the= > applicable data type (libguile procedures) being handled in a uniform > way without extra overhead in the case it "comes from the other > language." >=20 >>> - The handling of nil vs. Scheme #f and '() is admittedly a wart, but= >>> will probably remain hidden, not causing issues in code you write. >> >> I have problems seeing how it can remain hidden. >=20 > Please mention any concrete problematic cases you can think up. Imagine the round trip a value might take: #f in Scheme to nil in elisp to something back in Scheme. If you alias #f, (), and nil together from an elisp perspective, then when you need to differentiate these values, you can't, because you've just thrown away the information you'd need to do that. You can't make the object's true identity a hidden property of the value either, because that breaks perfectly valid code like this: (defun identity-x (x) (if (eq x nil) nil x)) 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. All in all, I think the effort would be better spent elsewhere. --h1N3Nqn5oFXNr5Ha9WnLS5PbXme5sqr01 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJUGg5xAAoJEN4WImmbpWBl0hUP/3IpjIhqsXtovzOmHzy1q0iW 9GDKXqdvixl16SrVBxSuVDY01HweO6TUCXMkd6e1KiVLlMZ7NA4JEQOCr5RLUOjt JpyvkiasXausRO/Cq3atLWu4yVViKGXvQezy5kU6MKEk9Y7yqORpEL7uuS/6lA4x aOtr2AfiNfyvIYzL1PaDNX7wpqjeFgU+dNqYRxO7P7LkZOmULpKqqa/vSVL+l5Jt oUFwUvNaYM62ORhBo37wJpFwMz4ldBP6V1QhbKqBXXVtGYX3aqgL5GGLSMtKY1Nb TIbYFwbh5sOctKlkzt1e1XeQSeLe7+um0i+qFoTGOjiPK2WcKMw3ZiFhLB/Zhw3h fZdH3zF1KvJNwGs+aA15peFd6WmaU9izAjUMfr/vgDeb8yPOlX0npRxGMKeCcqjA iXGAj/ScNPIRje+CkOMEnR44fDNeMewXKnV10jJhqqH4LHhOQXLLmIKABCeWrUNl vom0xImoFh3RffJRi7JXuwNje6uVO5tbxsP5t+IoZKvK3ADxXYfVvxpVM7ZaM3WI L+NepjlwRIocFUepaUmMZp1bNxIJUoHV3jv/Ur5ubhmJKjy+Ryj2uq7Y32cAK7zM AebM8kJAvglGMc340rCtCBSFmRYrQkws4jz8plrSvkT2PAdEQBqTvVebdGp7FpuY cO8UNRseDJPFGsf2hwOv =6W07 -----END PGP SIGNATURE----- --h1N3Nqn5oFXNr5Ha9WnLS5PbXme5sqr01--