From: His Holiness the Reverend Doktor Xenophon Fenderson, the Carbon(d)ated
Subject: RECURSIVE-P option to READ, READ-CHAR, etc?
Date: 
Message-ID: <w4obt7igwxy.fsf@nemesis.irtnog.org>
Just what, exactly, is the RECURSIVE-P option to READ and family
supposed to mean?  In CMUCL, I get the following:

* (read-char *standard-input* t nil t)
12345

#\1
* 
2345
*

And in Clisp, I get:

[1]> (read-char *standard-input* t nil t)
12345
#\1
[2]>
2345
[3]>

(Both on alpha-redhat-linux.)  The CLHS doesn't seem to go into great
detail in describing the semantics of the RECURSIVE-P option.

-- 
"What though the field be lost? / All is not lost; the unconquerable Will,
 And study of revenge, immortal hate, / And courage never to submit or yield."
   -- Lucifer,
      'Paradise Lost', Milton

From: Stig Hemmer
Subject: Re: RECURSIVE-P option to READ, READ-CHAR, etc?
Date: 
Message-ID: <ekvr9ge6kcd.fsf@epoksy.pvv.ntnu.no>
"His Holiness the Reverend Doktor Xenophon Fenderson, the Carbon(d)ated"
<········@irtnog.org> writes:
> Just what, exactly, is the RECURSIVE-P option to READ and family
> supposed to mean?

The RECURSIVE-P option should be set when you call READ and family
from reader macros.  It should not be set when you are just reading
normal input to your program.

E.g.: I have a reader macro that expands ?(blah blah).  It uses READ
with the RECURSIVE-P option set to read the list (blah blah).

This makes it possible to type things like

'(#1=blah ?(#1# bluh))

If I hadn't set RECURSIVE-P, the inner READ wouldn't have known what
to do with #1#.

There is also some other effect of RECURSIVE-P that eludes me at the
moment, but if you read the various entries in the Hyperspec for
READ-whatever you will find it there.

Stig Hemmer,
Jack of a Few Trades.
From: Barry Margolin
Subject: Re: RECURSIVE-P option to READ, READ-CHAR, etc?
Date: 
Message-ID: <s2C94.10$vN2.770@burlma1-snr2>
In article <···············@epoksy.pvv.ntnu.no>,
Stig Hemmer  <····@pvv.ntnu.no> wrote:
>There is also some other effect of RECURSIVE-P that eludes me at the
>moment, but if you read the various entries in the Hyperspec for
>READ-whatever you will find it there.

It has some effects on EOF error handling, IIRC.

-- 
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: His Holiness the Reverend Doktor Xenophon Fenderson, the Carbon(d)ated
Subject: Re: RECURSIVE-P option to READ, READ-CHAR, etc?
Date: 
Message-ID: <w4o3dsmobg7.fsf@nemesis.irtnog.org>
>>>>> "BM" == Barry Margolin <······@bbnplanet.com> writes:

    BM> It has some effects on EOF error handling, IIRC.

That seems to be the case (at least in CMUCL), but the "correct way"
to avoid eating EOFs is to use READ-PRESERVING-WHITESPACE, as
#\NEWLINE is a whitespace character in standard syntax.

-- 
"What though the field be lost? / All is not lost; the unconquerable Will,
 And study of revenge, immortal hate, / And courage never to submit or yield."
   -- Lucifer,
      'Paradise Lost', Milton
From: His Holiness the Reverend Doktor Xenophon Fenderson, the Carbon(d)ated
Subject: Re: RECURSIVE-P option to READ, READ-CHAR, etc?
Date: 
Message-ID: <w4owvpymvh4.fsf@nemesis.irtnog.org>
>>>>> "SH" == Stig Hemmer <····@pvv.ntnu.no> writes:

    SH> The RECURSIVE-P option should be set when you call READ and
    SH> family from reader macros.  It should not be set when you are
    SH> just reading normal input to your program.

Sure, I got that from reading the HyperSpec.  What I don't understand
is the setting's semantics, i.e. how it is supposed to affect the
reader algorithm.  I've never used the #= and ## macros, though, so
maybe reading up on those is in order.

    SH> There is also some other effect of RECURSIVE-P that eludes me
    SH> at the moment, but if you read the various entries in the
    SH> Hyperspec for READ-whatever you will find it there.

Crap.  I just found it.  It's section 23.1.3.2 "The RECURSIVE-P
argument".  Fortunately, no one has roasted me with request to kindly
investigate the relevant documentation.  =)  In fact, section 23.1.3
answers my questions about EOF-ERROR-P, as well.  Strange how that
happens when one actually reads the standard (instead of glossing over
the index), isn't it?

Sorry to bother everyone.  I'll go back to lurking now.

-- 
"What though the field be lost? / All is not lost; the unconquerable Will,
 And study of revenge, immortal hate, / And courage never to submit or yield."
   -- Lucifer,
      'Paradise Lost', Milton