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: [PATCH] Clojure-like syntactic sugar for an anonymous function literal Date: Fri, 23 Jan 2015 03:50:52 -0800 Message-ID: <54C2359C.3000600@dancol.org> References: <54C15ECA.5050008@dancol.org> <87egqlvl86.fsf@newcastle.ac.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SnbipPRhWci0Je9BDtNJKmxRdjD7v95Ff" X-Trace: ger.gmane.org 1422013872 10889 80.91.229.3 (23 Jan 2015 11:51:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 23 Jan 2015 11:51:12 +0000 (UTC) Cc: Oleh , emacs-devel@gnu.org To: Phillip Lord , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 23 12:51:11 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 1YEcla-0005g0-CT for ged-emacs-devel@m.gmane.org; Fri, 23 Jan 2015 12:51:10 +0100 Original-Received: from localhost ([::1]:58268 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEclU-0000fb-PF for ged-emacs-devel@m.gmane.org; Fri, 23 Jan 2015 06:51:04 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56410) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEclM-0000fR-Ih for emacs-devel@gnu.org; Fri, 23 Jan 2015 06:51:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YEclL-0002Gr-LR for emacs-devel@gnu.org; Fri, 23 Jan 2015 06:50:56 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:39457) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEclL-0002Gg-CK for emacs-devel@gnu.org; Fri, 23 Jan 2015 06:50:55 -0500 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=K45/JqqUtQHoZ48S5MerCp6zYxGQ/3pi+o7ejQx17GA=; b=NzwWBJ+sAeXEmp9n51Ig7XCfz4fB2OnVKG9SSuwoemhdUnQqL7iy28P6biLORnGSERoRuzN7NJ9W0ccrwwNhEeWARQnFhvijj7UGHzDfVwqN4xPSCOHqEmwaZawChXPqmqKHcqQDABHkqbfMS2ep3dCDOCiWeXEM/gj5jUNxYatEyqI9PgJ6a0Xtz7Gopl8IWPNpbNdV0LqPfV7MLE6d6gajiMCTI44HYRxs4ST8SnzD510U86t03bb+lWedy54Ls+FYdmd0Reg02IrQ1wQvZE4WDPEuF26yTu9hCxNij91QfxSdOM2mJPrYme9cy+l1wclo1wFWNqE9hY+ESuKb1Q==; Original-Received: from [2601:8:b240:93::2b1] by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1YEclJ-0002gW-69; Fri, 23 Jan 2015 03:50:53 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 In-Reply-To: <87egqlvl86.fsf@newcastle.ac.uk> 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:181664 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SnbipPRhWci0Je9BDtNJKmxRdjD7v95Ff Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 01/23/2015 02:34 AM, Phillip Lord wrote: > Stefan Monnier writes: >=20 >>> That's a problem with any lisp that provides a reader-macro facility.= >>> The onus is on the authors of macro packages to create macros that wo= rk >>> well with the existing emacs-lisp-mode parser. >> >> That's a good point. >> >>>>> So I'm currently against addition of CL style reader macros. >>> Stefan, is emacs-lisp-mode support your only objection? >> >> Yes and no. No in the sense that I expect that introducing such reade= r >> macros will have consequences that go further than just "emacs-lisp-mo= de >> support". >> >> Maybe we could introduce a more limited form of reader macros. >> E.g. allow # and make the reader return >> >> (funcall (cdr (assq reader-macro-alist)) ) >=20 > Would it not be possible to have the reader return a macro which could > do the cdr and assq at compile time and obviate the need for funcall? > This would be faster. It means that changes to reader-macro-alist > wouldn't be reflected in code till it was re-evaled. This paragraph is hard to parse, but ITYM that instead of literally calling funcall as Stefan described, the reader would mechanically transform _any_ construct of the form #LS, L being a letter and S being a sexp, into something like (expand-reader-macro 'L 'S). Maybe that could work, if the scoping rules (see below) were preserved. In any case, it's just an implementation detail. > My main concern with this as a proposal is that is a fairly > small namespace. There is a lot of possibility for pretty disasterous > clashes if this gets used in the wild. Of course. That's why we'd make each file register an association between letters and the macros to which they'd expand. Think of how XML namespaces map short local names to long global names. We'd make this mapping buffer-local, like lexical-binding. --SnbipPRhWci0Je9BDtNJKmxRdjD7v95Ff 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 iQIcBAEBCAAGBQJUwjWcAAoJEN4WImmbpWBl4f8QAJTxlECTN4c3bBBK0ONJzw03 kXb7DRzwchbNWvoaFZwnIvaUy7TwXgRC4uLabZy61Cbjok5MQquZ7cx73Le+vpni Idq7wYtgn+dnUznBio4xveGQ4JTUIT4Px7tijcw4TAnraPqPW/h+OTv9nN3pE0p7 eBHfJy5MSZJpsC/gn9R3X/hAI5jGUZb9APmVACix3k/UvgHd4mPUjBQZJAiLdsWf stKiSHqgZOa+BbpMGTzrq/UsM8g61Ypm0GjhsGQnkqMS65qyyFAhoJklyQmf4wbw JgXuv5+XbVY9wxmPzLm05EoibpW0bgapLbutH5/ve01UM6A35mWgmi+OWfD9/OoL MPImm24Ccu7+IArQS+1RTqnLW52/oiQtKGk2nAfDzXncBnN1xo5XOHckxdaRA/rb 5taQd+UMRYjsnLMPrPi1v9euzUnZ6Q/C8VF5ML8yGznyrVmYug8syQlgVPz7ho7c FZeME4fFmrQl9q3/U1L0axMahuInjRUBPizNOLegCM2gOGbXogUubEtLjjY2eP+9 tlJDdFG9MMKD6BIy55uN2qW60digCBhILK+Njvqiz3OEyOe8sS9a0bUPF7wyYcg4 2tcsQefW9wBZSKiYcn4B13RmQTORTdMAj8lRP6z1IMcYd0oEKJBl0KfqJLstSNJb /KBSmXx7PU2q5iI48zN4 =hgq+ -----END PGP SIGNATURE----- --SnbipPRhWci0Je9BDtNJKmxRdjD7v95Ff--