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: Re: REPL and load deifferences (was Re: Proposal for a new (ice-9 history)) Date: Tue, 30 Oct 2018 13:20:54 +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/mixed; boundary="0000000000006d066605797138dd" X-Trace: blaine.gmane.org 1540901968 9849 195.159.176.226 (30 Oct 2018 12:19:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 Oct 2018 12:19:28 +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 13:19:24 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 1gHSzT-0002Sj-QR for guile-devel@m.gmane.org; Tue, 30 Oct 2018 13:19:24 +0100 Original-Received: from localhost ([::1]:52849 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHT1X-0001nv-JI for guile-devel@m.gmane.org; Tue, 30 Oct 2018 08:21:31 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55206) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHT1H-0001ne-LV for guile-devel@gnu.org; Tue, 30 Oct 2018 08:21:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gHT1B-0005nD-Qy for guile-devel@gnu.org; Tue, 30 Oct 2018 08:21:14 -0400 Original-Received: from mail-ot1-f41.google.com ([209.85.210.41]:37648) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gHT1B-0005mk-J4 for guile-devel@gnu.org; Tue, 30 Oct 2018 08:21:09 -0400 Original-Received: by mail-ot1-f41.google.com with SMTP id o14so10851224oth.4 for ; Tue, 30 Oct 2018 05:21:09 -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=zYgZzNUvxdhUnbFqmAWIswLLAsEOC+GoVgep438SD+w=; b=Y8gjjbQ2zykiBljHSJ9F2mZKjNm3rZOAa+4q0yOSZZ+Jzv9UMCx2v1MNat9L42KxmG lL7uJEBMDBg+vhCnNGfl2eqkMm7zxnj45JEGwDdWw6AqaT8ITnIZB/k+2gEu9901mDiZ NrxY1EdPZrCjWQL6K08mK6Brgga2PxrwbNAxbg5H+hj2cnalpnAJoPwmdIFG0sfmH09n VxNk0TwAuEm2iIAQdZnFzIF3Kw75JsnS85Gsl77hprueoZ8kxcjOtUWbfjxrqFkFbgE2 vF6Py0xraTil+fW4zPQAK+tfeXi6aK6++Xx50wCWoLmH8qL56zEzH52Kp4vurKXCE9R/ kv9w== X-Gm-Message-State: AGRZ1gLPgiMeLHapGzKvgukGOXDKsMEWxM8kd6JGFmI0PkG2fipEVmIv nh1FZlt33I37icU4dQSTdLVzBZLKsWjsIoxuBXo= X-Google-Smtp-Source: AJdET5fgciDPtaBSCQdFHNR3WQEQyXUmh/ccBkW2y65P5iD7SIrbzoNkXJ4qWdOAmQj3POqkz1CbgsqU+rQNXJAnbMY= X-Received: by 2002:a9d:fe9:: with SMTP id m38mr10837363otd.2.1540902068478; Tue, 30 Oct 2018 05:21:08 -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.41 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:19705 Archived-At: --0000000000006d066605797138dd Content-Type: multipart/alternative; boundary="0000000000006d066205797138db" --0000000000006d066205797138db Content-Type: text/plain; charset="UTF-8" And, the attachments... On Tue, Oct 30, 2018 at 11:21 AM Mikael Djurfeldt wrote: > 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 > > --0000000000006d066205797138db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
And, the attachments...

On Tue, Oct 30, 2018 at 11:21 AM Mikael Djurfeldt &l= t;mikael@djurfeldt.com> wrot= e:
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@netri= s.org> wrote:=C2=A0
=C2=A0 More precisely, it is a literal
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

--0000000000006d066205797138db-- --0000000000006d066605797138dd Content-Type: text/x-scheme; charset="US-ASCII"; name="matchcoll.scm" Content-Disposition: attachment; filename="matchcoll.scm" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_jnvpajkj0 KHVzZS1tb2R1bGVzIChpY2UtOSBtYXRjaCkpCih1c2UtbW9kdWxlcyAoc3JmaSBzcmZpLTkpKQoo ZGVmaW5lLXJlY29yZC10eXBlIDxmb28+IChtYWtlLWZvbyBhIGIpIGZvbz8gKGEgZm9vLWEpIChi IGZvby1iKSkKKG1hdGNoIChtYWtlLWZvbyAxIDIpICgoJCA8Zm9vPiBhIGIpICgrIGEgYikpKQoK KGRlZmluZSAkICdibGFoKQoobWF0Y2ggKG1ha2UtZm9vIDEgMikgKCgkIDxmb28+IGEgYikgKCsg YSBiKSkpCg== --0000000000006d066605797138dd Content-Type: text/x-scheme; charset="US-ASCII"; name="elsetest.scm" Content-Disposition: attachment; filename="elsetest.scm" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_jnvpaohm1 KGRpc3BsYXkgKGNvbmQgKGVsc2UgI3QpKSkKKG5ld2xpbmUpCgooZGVmaW5lIGVsc2UgI2YpCgoo ZGlzcGxheSAoY29uZCAoZWxzZSAjdCkpKQoobmV3bGluZSkK --0000000000006d066605797138dd--