unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Mikael Djurfeldt <mikael@djurfeldt.com>
To: Mark H Weaver <mhw@netris.org>
Cc: guile-devel <guile-devel@gnu.org>
Subject: Re: REPL and load deifferences (was Re: Proposal for a new (ice-9 history))
Date: Tue, 30 Oct 2018 13:20:54 +0100	[thread overview]
Message-ID: <CAA2XvwLYWc=r7fry_1Ve9bEsiUtOPrpBgcMpAAVmhwY3=LYqzw@mail.gmail.com> (raw)
In-Reply-To: <CAA2XvwK_S1j8ops5aqvWCtcj0ToLRkSYms00-KcYigGB4Os4ow@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 3847 bytes --]

And, the attachments...

On Tue, Oct 30, 2018 at 11:21 AM Mikael Djurfeldt <mikael@djurfeldt.com>
wrote:

> 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:
>>
>>>   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 <literals> 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 <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 = 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.  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 #<unspecified>, 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 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
>
>

[-- Attachment #1.2: Type: text/html, Size: 5199 bytes --]

[-- Attachment #2: matchcoll.scm --]
[-- Type: text/x-scheme, Size: 235 bytes --]

(use-modules (ice-9 match))
(use-modules (srfi srfi-9))
(define-record-type <foo> (make-foo a b) foo? (a foo-a) (b foo-b))
(match (make-foo 1 2) (($ <foo> a b) (+ a b)))

(define $ 'blah)
(match (make-foo 1 2) (($ <foo> a b) (+ a b)))

[-- Attachment #3: elsetest.scm --]
[-- Type: text/x-scheme, Size: 93 bytes --]

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

(define else #f)

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

  reply	other threads:[~2018-10-30 12:20 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-29 14:13 Proposal for a new (ice-9 history) Mikael Djurfeldt
2018-10-29 23:54 ` Mark H Weaver
2018-10-30  0:55   ` Mikael Djurfeldt
2018-10-30 10:21     ` REPL and load deifferences (was Re: Proposal for a new (ice-9 history)) Mikael Djurfeldt
2018-10-30 12:20       ` Mikael Djurfeldt [this message]
2018-10-30 18:01         ` Göran Weinholt
2018-10-30  0:25 ` Proposal for a new (ice-9 history) Mark H Weaver
2018-10-30  1:08   ` Mikael Djurfeldt
2018-10-30  6:20     ` Mark H Weaver
2018-10-30 13:59       ` Mikael Djurfeldt
2018-10-31 16:49         ` Mikael Djurfeldt
2018-11-02 13:35           ` Mikael Djurfeldt
2018-11-02 14:02             ` Mikael Djurfeldt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAA2XvwLYWc=r7fry_1Ve9bEsiUtOPrpBgcMpAAVmhwY3=LYqzw@mail.gmail.com' \
    --to=mikael@djurfeldt.com \
    --cc=guile-devel@gnu.org \
    --cc=mhw@netris.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).