From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: Feature request: Expose `ellipsis?' from psyntax.ss Date: Fri, 23 Nov 2018 02:55:41 -0500 Message-ID: <87d0qwqlbb.fsf@netris.org> References: <875zwzmq4n.fsf@netris.org> <87pnv6iss7.fsf@netris.org> <87k1leip2i.fsf@netris.org> <124085ab-2a76-4892-e790-d58b07bcb3fc@nieper-wisskirchen.de> <87lg5tj3gn.fsf@netris.org> <874lcgzj9p.fsf@netris.org> <871s7fuml7.fsf@netris.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1542959688 17982 195.159.176.226 (23 Nov 2018 07:54:48 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 23 Nov 2018 07:54:48 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Cc: guile-devel@gnu.org To: Marc =?utf-8?Q?Nieper-Wi=C3=9Fkirchen?= Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Nov 23 08:54:44 2018 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gQ6IW-0004Zb-FD for guile-devel@m.gmane.org; Fri, 23 Nov 2018 08:54:44 +0100 Original-Received: from localhost ([::1]:50890 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gQ6Kd-0002lX-0g for guile-devel@m.gmane.org; Fri, 23 Nov 2018 02:56:55 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58451) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gQ6KM-0002lO-6h for guile-devel@gnu.org; Fri, 23 Nov 2018 02:56:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gQ6KI-0006rY-LE for guile-devel@gnu.org; Fri, 23 Nov 2018 02:56:37 -0500 Original-Received: from world.peace.net ([64.112.178.59]:45918) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gQ6KI-0006fG-Hu for guile-devel@gnu.org; Fri, 23 Nov 2018 02:56:34 -0500 Original-Received: from mhw by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gQ6K7-0003ot-7g; Fri, 23 Nov 2018 02:56:23 -0500 In-Reply-To: ("Marc \=\?utf-8\?Q\?Nieper-Wi\=C3\=9Fkirchen\=22's\?\= message of "Wed, 21 Nov 2018 09:40:36 +0100") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 64.112.178.59 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:19760 Archived-At: Hi Marc, Marc Nieper-Wi=C3=9Fkirchen writes: > Am Mi., 21. Nov. 2018 um 04:38 Uhr schrieb Mark H Weaver : > > > Ellipsis identifiers are a bit more tricky, because unlike other > > bindings, the user-visible ellipsis identifiers are not actually > > substituted. We can't do that because ellipsis identifiers can be us= ed > > for other purposes, e.g. bound to ordinary variables or macros, and > > these two ways of binding ellipsis identifiers should not shadow each > > other. Sorry, this was a weak argument. I've since remembered the _actual_ reason that it needs to be done this way: In general, for any sensible binding form, bindings with different names should not shadow each other. For example, a binding for 'E' should not shadow a binding for 'F'. If you try to model (with-ellipsis E BODY) as binding 'E', then it is not a sensible binding form in this sense. Unlike any sensible binding form, (with-ellipsis E BODY) should not only shadow outer bindings of 'E', but *any* outer ellipsis binding, whether '...' or 'F' or something else. In other words, in this model, there can be only one binding of this kind in a given lexical context. Therefore, I think this is a bad model for 'with-ellipsis'. I think it makes more sense to model (with-ellipsis E BODY) as introducing a new lexical binding with a fixed name. CURRENT-ELLIPSIS would be a good name if we wanted to make it part of the public API. In this model, 'E' becomes the _value_ of the binding, instead of the binding's name. Does that make sense? Note that in this later model, it's not natural for (with-ellipsis E BODY) to shadow a binding for 'E' or vice versa, because 'E' is not actually the thing being bound by 'with-ellipsis'. In theory, we could introduce additional mechanisms to force (with-ellipsis E BODY) to shadow bindings for 'E' and vice versa. This would entail changing *every* binding form to check if the identifier being bound matches the current binding of CURRENT-ELLIPSIS, and if so, somehow invalidating the ellipsis binding. It's not obvious what should be done in this case. We could do something like this, but in my view, it would be an ad-hoc addition to the semantics in order to support the inadequate mental model where (with-ellipsis E BODY) is thought of as binding 'E'. What do you think? Mark