From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: David Kastrup Newsgroups: gmane.lisp.guile.devel Subject: Re: unhandled constant? Date: Sat, 01 Feb 2020 15:23:12 +0100 Message-ID: <877e16v12n.fsf@fencepost.gnu.org> References: <8d77f905-31e9-4d0b-973a-82be38360e07@www.fastmail.com> <877e16wolr.fsf@fencepost.gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="102542"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: guile-devel@gnu.org, Han-Wen Nienhuys To: Linus =?iso-8859-1?Q?Bj=F6rnstam?= Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Sat Feb 01 15:23:34 2020 Return-path: Envelope-to: guile-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ixtgL-000QYp-Si for guile-devel@m.gmane-mx.org; Sat, 01 Feb 2020 15:23:33 +0100 Original-Received: from localhost ([::1]:46662 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ixtgK-00008S-VC for guile-devel@m.gmane-mx.org; Sat, 01 Feb 2020 09:23:32 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55765) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ixtg5-00007s-5h for guile-devel@gnu.org; Sat, 01 Feb 2020 09:23:18 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38385) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ixtg5-0001Ce-0i; Sat, 01 Feb 2020 09:23:17 -0500 Original-Received: from x2f31156.dyn.telefonica.de ([2.243.17.86]:37460 helo=lola) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ixtg3-000858-9r; Sat, 01 Feb 2020 09:23:16 -0500 In-Reply-To: ("Linus =?iso-8859-1?Q?Bj=F6rnstam=22's?= message of "Sat, 01 Feb 2020 14:16:36 +0100") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.io gmane.lisp.guile.devel:20373 Archived-At: Linus Bj=F6rnstam writes: > On Sat, 1 Feb 2020, at 12:09, David Kastrup wrote: >>=20 >> Can you expand about the "expansion time and macro time separation"? >>=20 >> If we have >>=20 >> (define decl '()) >> (define (make-var n v) (list "var" n v)) >> (defmacro define-session (name value) >> (define (inner n v) >> (set! decl >> (cons >> (make-var n v) >> decl)) >> ) >> `(,inner ',name ,value)) >> (define-session foo 1) >> (display decl) >> (newline) >>=20 >> as stated, the local function "inner" is defined at macro time, but the >> form >> `(,inner ',name ,value) >> does not export the _name_ inner but rather the defined function. That >> part naively appears to me like it should work; an "expansion time and >> macro time" issue appears rather to be that inner calls make-var (and >> accesses decl) which is only being defined at expansion time. >>=20 >> The error message, however, rather appears to complain about inner being >> undefined rather than the definition of inner referring to undefined >> entities. > > > I am not sure what is really the problem. Either the inner function is > not present at runtime due to separation of compile time and runtime, > or it is a result of how defmacro re-introduces the result of the > macro into the syntactic context of the macro usage (where inner is > not visible). Either way, having the inner definition in the macro > output will solve the problem of it not being visible. This fails when byte-compiling, so it would appear that the equivalent of (defmacro ... (define local-fun ... `(,local-fun ...))) is not able to represent the local (and thus ultimately anonymous) function here. Whether this is a general shortcoming or is conditioned on local-fun calling functions not available at byte-compile time (in which case those would need to get wrapped in eval-and-expand) I haven't checked yet. --=20 David Kastrup