Subject: Re: bug#14164: letrec: detect illegal accesses to vars before entering body

From: Mark H Weaver <[email-masked]>
Date: Wed, 10 Apr 2013 05:25:20 -0400

Nikita Karetnikov <[email-masked]> writes:

>> I'll fix the manual.
>
> Thanks.
>
> So what's the difference between 'letrec' and 'letrec*', then?  I fail
> to grasp it.

The difference is that in 'letrec*', the initializers are guaranteed to
be evaluated in order, and they are allowed to access earlier bindings
before entering the body.  In 'letrec', the order in which the
initializers are evaluated is unspecified, and they are *not* allowed to
access earlier bindings.

> Could you add a relevant example to the manual?

The example given in the manual under 'letrec*' was basically correct.
The only problem was that it shouldn't have claimed that an error would
be reported to the user.

Here's the change I made to the manual:

--8<---------------cut here---------------start------------->8---
index 5763f36..e3a9918 100644 (file)
--- a/doc/ref/api-binding.texi
+++ b/doc/ref/api-binding.texi
@@ -218,9 +218,9 @@ variables.
 
 @lisp
 (letrec ((a 42)
-         (b (+ a 10)))
+         (b (+ a 10)))  ;; Illegal access
   (* a b))
-@result{} ;; Error: unbound variable: a
+;; The behavior of the expression above is unspecified
 
 (letrec* ((a 42)
           (b (+ a 10)))
  (* a b))
@result{} 2184
@end lisp
--8<---------------cut here---------------end--------------->8---

>> 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.
>
> Just to clarify: When the standard says "unspecified," I can read it as
> "it's up to the particular implementation (e.g., Guile)," right?

Yes, but keep in mind that there's no guarantee that the results will be
consistent from one evaluation to the next, even within a particular
implementation.  For example, the 'letrec' above could return a random
number each time it is run, or even crash randomly, though that would
clearly be undesirable and we would seek to avoid that in Guile.

     Regards,
       Mark