[wilson@cs.utexas.edu]
>I think I may have been wrong about this [distinction of #f and '()
>being unspecified in R4RS], and someone corrected me.
>
>I think it has been said that the R5RS will make it clear that that
>'() and #f must be distinct objects.
I apologize. I must have missed this.
[bothner@cygnus.com]
>In any case, both IEEE Scheme and R5RS require
>that () is not #t, so we should aim for that.
I knew about IEEE Scheme but not considered it crucial (there is no
freely redistributable specification of IEEE Scheme, as far as I know).
I did not know about R5RS (or its expected intent).
[perry@piermont.com]
>I don't believe there is one [R5RS draft], but a discussion of what
>was decided is available off of the scheme home page,
>http://www-swiss.ai.mit.edu/scheme-home.html
I have looked it up. The relevant document is "The Scheme of Things:
The June 1992 Meeting" by Jonathan Rees (article appeared in Lisp
Pointers V(4), Oct-Dec 1992) and I quote:
[...] purpose of the meeting was to work on the technical
content of the next revision of the Scheme report.
[...]
Norman Adams was appointed the Revised^5 Report's editor. It
is hoped that it will be ready by early 1993, so as to precede
the reconstitution of the IEEE standard group.
[...]
Until now, the Scheme reports have encouraged but not required
the empty list `()' and the boolean false value `#f' to be
distinct. It has been the intent ever since the Revised
Revised Report, however, that this distinction would
eventually be required. The IEEE Scheme standard bit the
bullet in 1990, and now the Revised^5 report follows.
It seems to be the case that Scheme standartization process is indeed
seriously aiming for compulsory #f vs. () distinction.
Now I start to understand the trade-offs behind Jim Blandy's proposal
of Guile <-> Emacs Lisp interaction somewhat better.
Thank you for all the replies and clarifications.
-- Petr Adamek
P.S.: I wish there were a positive rationale for the () vs. #f
distinction in Scheme FAQ, with specific code style example(s)
pointing out the advantage over the traditional Lisp convention. But
this is not a Guile agenda.