GNU bug report logs - #10491
unread-char and eof

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10491 in the body.
You can then email your comments to 10491 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Aleix Conchillo Flaqué <aconchillo <at> gmail.com>
To: bug-guile <at> gnu.org
Subject: unread-char and eof
Date: Thu, 12 Jan 2012 12:14:04 -0800

Whenever eof is reach in a port, a call to unread-char passing eof
triggers an error. I'm not sure what's the right behavior for this,
but I guess the way it is now is just as the user should be
responsible to check eof.

A note in the documentation would help in any case.

Message #8 received at 10491 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Hartwig <mandyke <at> gmail.com>
To: Aleix Conchillo Flaqué <aconchillo <at> gmail.com>
Cc: 10491 <at> debbugs.gnu.org
Subject: Re: bug#10491: unread-char and eof
Date: Fri, 13 Jan 2012 18:34:39 +0800

On 13 January 2012 04:14, Aleix Conchillo Flaqué <aconchillo <at> gmail.com> wrote:
> Whenever eof is reach in a port, a call to unread-char passing eof
> triggers an error. I'm not sure what's the right behavior for this,
> but I guess the way it is now is just as the user should be
> responsible to check eof.

The user should indeed be checking for this because eof is not a
character, rather, a special value used to indicate that no more data
is available on the port.  This value is not read from the port, it
does not make sense to unread it.

>
> A note in the documentation would help in any case.

Suggestions welcome.  Personally I find the documentation sufficiently
clear on the usage of unread-char only accepting a character value and
equally clear that an eof value is not a character.

Message #11 received at 10491 <at> debbugs.gnu.org (full text, mbox):

From: Aleix Conchillo Flaqué <aconchillo <at> gmail.com>
To: Daniel Hartwig <mandyke <at> gmail.com>
Cc: 10491 <at> debbugs.gnu.org
Subject: Re: bug#10491: unread-char and eof
Date: Mon, 16 Jan 2012 10:57:44 -0800

On Fri, Jan 13, 2012 at 2:34 AM, Daniel Hartwig <mandyke <at> gmail.com> wrote:
>
> Suggestions welcome.  Personally I find the documentation sufficiently
> clear on the usage of unread-char only accepting a character value and
> equally clear that an eof value is not a character.

I totally agree. However, I think the documentation should help any
kind of user level. The documentation also does not say of any kind of
error reported by the function.

So, something like this, I think would help:

"Procedure will report an error if a non-character object (e.g.
end-of-file object) is given to it.".

Or something similar.

I don't have a strong opinion on this, so you can certainly mark the
bug as won't do. But I think it would help.

Best,

Aleix

Message #14 received at 10491 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Hartwig <mandyke <at> gmail.com>
To: Aleix Conchillo Flaqué <aconchillo <at> gmail.com>
Cc: 10491 <at> debbugs.gnu.org
Subject: Re: bug#10491: unread-char and eof
Date: Tue, 17 Jan 2012 11:31:12 +0800

On 17 January 2012 02:57, Aleix Conchillo Flaqué <aconchillo <at> gmail.com> wrote:
>
> I totally agree. However, I think the documentation should help any
> kind of user level. The documentation also does not say of any kind of
> error reported by the function.

Nor are type errors mentioned by most other functions, they are simply
implied.  This convention is mentioned in the revised report [1]:

 It is an error for an operation to be presented with an argument that it
 is not specified to handle.  For succinctness, we follow the convention
 that if an argument name is also the name of a type listed in section
 *note Disjointness of types::, then that argument must be of the named
 type.  For example, ...

[1] http://people.csail.mit.edu/jaffer/r5rs_3.html#SEC11

Message #17 received at 10491 <at> debbugs.gnu.org (full text, mbox):

From: Aleix Conchillo Flaqué <aconchillo <at> gmail.com>
To: Daniel Hartwig <mandyke <at> gmail.com>
Cc: 10491 <at> debbugs.gnu.org
Subject: Re: bug#10491: unread-char and eof
Date: Tue, 17 Jan 2012 16:57:37 -0800

On Mon, Jan 16, 2012 at 7:31 PM, Daniel Hartwig <mandyke <at> gmail.com> wrote:
>
> Nor are type errors mentioned by most other functions, they are simply
> implied.  This convention is mentioned in the revised report [1]:
>
>  It is an error for an operation to be presented with an argument that it
>  is not specified to handle.  For succinctness, we follow the convention
>  that if an argument name is also the name of a type listed in section
>  *note Disjointness of types::, then that argument must be of the named
>  type.  For example, ...
>
> [1] http://people.csail.mit.edu/jaffer/r5rs_3.html#SEC11


I see, convinced. Thanks for the feedback.

You can mark it as invalid and close it.

Message #22 received at 10491-done <at> debbugs.gnu.org (full text, mbox):

From: Daniel Hartwig <mandyke <at> gmail.com>
To: 10491-done <at> debbugs.gnu.org
Subject: Re: bug#10491: unread-char and eof
Date: Wed, 18 Jan 2012 09:07:31 +0800

On 18 January 2012 08:57, Aleix Conchillo Flaqué <aconchillo <at> gmail.com> wrote:
> On Mon, Jan 16, 2012 at 7:31 PM, Daniel Hartwig <mandyke <at> gmail.com> wrote:
>>
>> Nor are type errors mentioned by most other functions, they are simply
>> implied.  This convention is mentioned in the revised report [1]:
>>
>>  It is an error for an operation to be presented with an argument that it
>>  is not specified to handle.  For succinctness, we follow the convention
>>  that if an argument name is also the name of a type listed in section
>>  *note Disjointness of types::, then that argument must be of the named
>>  type.  For example, ...
>>
>> [1] http://people.csail.mit.edu/jaffer/r5rs_3.html#SEC11
>
>
> I see, convinced. Thanks for the feedback.
>
> You can mark it as invalid and close it.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.