unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: Nikita Karetnikov <nikita@karetnikov.org>
Cc: 14164@debbugs.gnu.org
Subject: bug#14164: letrec: detect illegal accesses to vars before entering body
Date: Tue, 09 Apr 2013 12:44:07 -0400	[thread overview]
Message-ID: <87wqsbd57s.fsf@tines.lan> (raw)
In-Reply-To: <87mwt8p5u5.fsf@karetnikov.org> (Nikita Karetnikov's message of "Tue, 09 Apr 2013 10:37:38 +0400")

Nikita Karetnikov <nikita@karetnikov.org> writes:

>>> According to the manual [1], this snippet:
>>>
>>> (letrec ((a 42)
>>>          (b (+ a 10)))
>>>   (* a b))
>>>
>>> should return "Error: unbound variable: a."
>
>> The manual doesn't say anything nearly that specific.
>
> Either you missed it or I misunderstood this sentence.  So if you missed
> it, it can be found below 'syntax: letrec* bindings body'.

Oops!  You're right, of course.  Apologies for saying you were wrong.
I'll fix the manual.

>> In general, if the manual says you "may not" do something, or if the
>> R5RS says "it is an error", that means that if you do, the results are
>> unspecified.
>
> Are you talking about the result of 'letrec' or 'b'?  Anyway, why does
> it return 2184 if the results are unspecified?  Could you elaborate?

Well, first of all, I misspoke.  In this case, I should have said (as
the R5RS did) that "it is an error", which in Scheme-standard-speak
means "anything at all could happen".  This is different from "an error
is signaled" or "an error is raised" or "an exception is thrown" which
consitutes a promise to report an error.

When the standard (or the manual) says "the result is unspecified", that
means that some value will be returned, but that value could be
anything.

Although Guile includes a distinguished value shown as "*unspecified*",
which is often used in these cases, it is not always used.  In practice,
we use it when we can easily do so without imposing a runtime cost, as a
debugging aid.  However, it is not always used.

     Thanks,
       Mark





  reply	other threads:[~2013-04-09 16:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-09  4:41 bug#14164: 'letrec' allows to refer to the values of previously bound variables Nikita Karetnikov
2013-04-09  5:14 ` bug#14164: letrec: detect illegal accesses to vars before entering body Mark H Weaver
2013-04-09  6:37   ` Nikita Karetnikov
2013-04-09 16:44     ` Mark H Weaver [this message]
2013-04-09 17:22       ` Nikita Karetnikov
2013-04-10  9:25         ` Mark H Weaver
2013-04-12  8:43           ` Ludovic Courtès

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=87wqsbd57s.fsf@tines.lan \
    --to=mhw@netris.org \
    --cc=14164@debbugs.gnu.org \
    --cc=nikita@karetnikov.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).