From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Mikael Djurfeldt Newsgroups: gmane.lisp.guile.devel Subject: REPL and load deifferences (was Re: Proposal for a new (ice-9 history)) Date: Tue, 30 Oct 2018 11:21:19 +0100 Message-ID: References: <87pnvsmhq6.fsf@netris.org> Reply-To: mikael@djurfeldt.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000a47eea05796f8c04" X-Trace: blaine.gmane.org 1540894786 5302 195.159.176.226 (30 Oct 2018 10:19:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 Oct 2018 10:19:46 +0000 (UTC) Cc: guile-devel To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Oct 30 11:19:42 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 1gHR7Y-0001BE-VM for guile-devel@m.gmane.org; Tue, 30 Oct 2018 11:19:37 +0100 Original-Received: from localhost ([::1]:51979 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHR9f-0007jK-0b for guile-devel@m.gmane.org; Tue, 30 Oct 2018 06:21:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36382) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHR9Z-0007j3-KP for guile-devel@gnu.org; Tue, 30 Oct 2018 06:21:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gHR9V-00022p-Jg for guile-devel@gnu.org; Tue, 30 Oct 2018 06:21:41 -0400 Original-Received: from mail-ot1-f44.google.com ([209.85.210.44]:41395) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gHR9T-0001zy-LF for guile-devel@gnu.org; Tue, 30 Oct 2018 06:21:37 -0400 Original-Received: by mail-ot1-f44.google.com with SMTP id c32so10524065otb.8 for ; Tue, 30 Oct 2018 03:21:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=7U5XR1BE5wo7pUVa8Hic9o7stnIrmZVTe2vUjQP7MVU=; b=g86cpv1mejgZpYRwaFhL8pd+x27IaufSug/dSs7GOpO9oJNNYPfp5dhCaOOdc2bHoj qStvSsWJF+11Krlgl3ZjVmY/q3PKr9g1P3rxZWi4bU0zOVtWy0ZlrZipiLxoLsI0JkKU wGSAArWeV7hQbS7gGDuksbWROFxra+F3LPPnjRpxDI6Zi+Ld24jN7sZ5h9Fc4CR1TRM/ 6KvutWZ26H+8iwhi5DbnCOxMcb0IjzqRe6G3R14yIlvp0dYKR14Y08b3+3pf0XUhnvkS pdG3Q/5J0PXtKpeyWYqiTO6VQWZiezgJD6d+vMxM6BFO9gecjWlQtg11HMdbbdaHBJfK AfzA== X-Gm-Message-State: AGRZ1gLCpBfrJ6ij5X9V1mrVMwaL1ZA5FEatawHOVHXARBrm4ju+4tZY bjWZhlvGjFdlQofhi+33px+2tjkXQYdV1IEHvNI= X-Google-Smtp-Source: AJdET5erwwvTGZMp8UkNNPFI5A5YaTj2TIeDN6dp0bpPEInULBXVgtVUdXV4bkgFcu6b1fdVextst/q0hPuUD/cJfh0= X-Received: by 2002:a9d:837:: with SMTP id 52mr703710oty.143.1540894891473; Tue, 30 Oct 2018 03:21:31 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.210.44 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:19704 Archived-At: --000000000000a47eea05796f8c04 Content-Type: text/plain; charset="UTF-8" On Tue, Oct 30, 2018 at 1:55 AM Mikael Djurfeldt wrote: > On Tue, Oct 30, 2018 at 12:55 AM Mark H Weaver wrote: > >> More precisely, it is a literal >> identifier recognized by 'match' and related macros, in the same sense >> that 'else' and '=>' are literal identifiers recognized by the 'cond' >> macro. >> >> R5RS section 4.3.2 (Pattern language) specifies how these literal >> identifiers are to be compared with identifiers found in each macro use: >> >> Identifiers that appear in are interpreted as literal >> identifiers to be matched against corresponding subforms of the >> input. A subform in the input matches a literal identifier if and >> only if it is an identifier and either both its occurrence in the >> macro expression and its occurrence in the macro definition have >> the same lexical binding, or the two identifiers are equal and both >> have no lexical binding. >> >> The implication is that these literal identifiers such as 'else', '=>' >> and '$' lose their special meaning in any environment where they are >> bound, unless the same binding is visible in the corresponding macro >> definition environment. R6RS and R7RS also specify this behavior. >> >> For example: >> >> --8<---------------cut here---------------start------------->8--- >> mhw@jojen ~$ guile >> GNU Guile 2.2.3 >> Copyright (C) 1995-2017 Free Software Foundation, Inc. >> >> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. >> This program is free software, and you are welcome to redistribute it >> under certain conditions; type `,show c' for details. >> >> Enter `,help' for help. >> scheme@(guile-user)> ,use (ice-9 match) >> scheme@(guile-user)> ,use (srfi srfi-9) >> scheme@(guile-user)> (define-record-type (make-foo a b) foo? (a >> foo-a) (b foo-b)) >> scheme@(guile-user)> (match (make-foo 1 2) (($ a b) (+ a b))) >> $1 = 3 >> scheme@(guile-user)> (define $ 'blah) >> scheme@(guile-user)> (match (make-foo 1 2) (($ a b) (+ a b))) >> :6:0: Throw to key `match-error' with args `("match" "no >> matching pattern" #< a: 1 b: 2>)'. >> >> Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. >> scheme@(guile-user) [1]> >> --8<---------------cut here---------------end--------------->8--- >> > > Incidentally, this does *not* throw an error in master (unless I made some > mistake in this late hour), which then is a bug! > I now looked at this a bit more. It turns out that the difference is not between stable-2.2 and master, but between REPL and load. While I can reproduce the above also in master, if I instead load it (attached file matchcoll.scm), I get no error! Also, the following file (attached as "elsetest.scm"): ------------------------------ (display (cond (else #t))) (newline) (define else #f) (display (cond (else #t))) (newline) ------------------------------ gives the results #t and #, as expected, in the REPL, but if I load the file, I instead get: scheme@(guile-user)> (load "elsetest.scm") /home/mdj/guile/elsetest.scm:7:0: Unbound variable: else If I load it into Chez Scheme, I get: #t # as expected. Maybe someone more knowledgeable than myself could sort out what out of this is a bug? Also, I have to rant a bit about R5RS section 4.3.2. What a mess this is! To have the literals influenced by bindings outside goes against the spirit of lexical binding, in my opinion, where the idea is to be able to judge the outcome of the code from looking at it locally. Best regards, Mikael --000000000000a47eea05796f8c04 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Oct 30, 2018 at = 1:55 AM Mikael Djurfeldt <mikael= @djurfeldt.com> wrote:
On Tue, Oct 30, 2018 at= 12:55 AM Mark H Weaver <mhw@netris.org> wrote:=C2=A0
=C2=A0 More precisely, it is a li= teral
identifier recognized by 'match' and related macros, in the same se= nse
that 'else' and '=3D>' are literal identifiers recognize= d by the 'cond'
macro.

R5RS section 4.3.2 (Pattern language) specifies how these literal
identifiers are to be compared with identifiers found in each macro use:
=C2=A0 =C2=A0 =C2=A0Identifiers that appear in <literals> are interpr= eted as literal
=C2=A0 =C2=A0 =C2=A0identifiers to be matched against corresponding subform= s of the
=C2=A0 =C2=A0 =C2=A0input.=C2=A0 A subform in the input matches a literal i= dentifier if and
=C2=A0 =C2=A0 =C2=A0only if it is an identifier and either both its occurre= nce in the
=C2=A0 =C2=A0 =C2=A0macro expression and its occurrence in the macro defini= tion have
=C2=A0 =C2=A0 =C2=A0the same lexical binding, or the two identifiers are eq= ual and both
=C2=A0 =C2=A0 =C2=A0have no lexical binding.

The implication is that these literal identifiers such as 'else', &= #39;=3D>'
and '$' lose their special meaning in any environment where they ar= e
bound, unless the same binding is visible in the corresponding macro
definition environment.=C2=A0 R6RS and R7RS also specify this behavior.

For example:

--8<---------------cut here---------------start------------->8---
mhw@jojen ~$ guile
GNU Guile 2.2.3
Copyright (C) 1995-2017 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> ,use (ice-9 match)
scheme@(guile-user)> ,use (srfi srfi-9)
scheme@(guile-user)> (define-record-type <foo> (make-foo a b) foo?= (a foo-a) (b foo-b))
scheme@(guile-user)> (match (make-foo 1 2) (($ <foo> a b) (+ a b))= )
$1 =3D 3
scheme@(guile-user)> (define $ 'blah)
scheme@(guile-user)> (match (make-foo 1 2) (($ <foo> a b) (+ a b))= )
<unnamed port>:6:0: Throw to key `match-error' with args `("= match" "no matching pattern" #<<foo> a: 1 b: 2>)= '.

Entering a new prompt.=C2=A0 Type `,bt' for a backtrace or `,q' to = continue.
scheme@(guile-user) [1]>
--8<---------------cut here---------------end--------------->8---
=

Incidentally, this does *not* throw an err= or in master (unless I made some mistake in this late hour), which then is = a bug!

I now looked a= t this a bit more. It turns out that the difference is not between stable-2= .2 and master, but between REPL and load. While I can reproduce the above a= lso in master, if I instead load it (attached file matchcoll.scm), I get no= error!

Also, the following file (attached as= "elsetest.scm"):
------------------------------
<= div>(display (cond (else #t)))
(newline)

(define else #f)

= (display (cond (else #t)))
(newline)
---------------------------= ---

gives the results #t and #<unspecifie= d>, as expected, in the REPL, but if I load the file, I instead get:

scheme@(guile-user)> (load "elsetest.scm"= ;)
/home/mdj/guile/elsetest.scm:7:0: Unbound variable: else

If I load it into Chez Scheme, I get:

=
#t
#<void>

as expected.
=

Maybe someone more knowledgeable than myself could sort= out what out of this is a bug?

Also, I have to ra= nt a bit about R5RS section 4.3.2. What a mess this is! To have the literal= s influenced by bindings outside goes against the spirit of lexical binding= , in my opinion, where the idea is to be able to judge the outcome of the c= ode from looking at it locally.

Best regards,<= /div>
Mikael

--000000000000a47eea05796f8c04--