* bug#10491: unread-char and eof
@ 2012-01-12 20:14 Aleix Conchillo Flaqué
2012-01-13 10:34 ` Daniel Hartwig
0 siblings, 1 reply; 6+ messages in thread
From: Aleix Conchillo Flaqué @ 2012-01-12 20:14 UTC (permalink / raw)
To: 10491
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#10491: unread-char and eof
2012-01-12 20:14 bug#10491: unread-char and eof Aleix Conchillo Flaqué
@ 2012-01-13 10:34 ` Daniel Hartwig
2012-01-16 18:57 ` Aleix Conchillo Flaqué
0 siblings, 1 reply; 6+ messages in thread
From: Daniel Hartwig @ 2012-01-13 10:34 UTC (permalink / raw)
To: Aleix Conchillo Flaqué; +Cc: 10491
On 13 January 2012 04:14, Aleix Conchillo Flaqué <aconchillo@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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#10491: unread-char and eof
2012-01-13 10:34 ` Daniel Hartwig
@ 2012-01-16 18:57 ` Aleix Conchillo Flaqué
2012-01-17 3:31 ` Daniel Hartwig
0 siblings, 1 reply; 6+ messages in thread
From: Aleix Conchillo Flaqué @ 2012-01-16 18:57 UTC (permalink / raw)
To: Daniel Hartwig; +Cc: 10491
On Fri, Jan 13, 2012 at 2:34 AM, Daniel Hartwig <mandyke@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
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#10491: unread-char and eof
2012-01-16 18:57 ` Aleix Conchillo Flaqué
@ 2012-01-17 3:31 ` Daniel Hartwig
2012-01-18 0:57 ` Aleix Conchillo Flaqué
0 siblings, 1 reply; 6+ messages in thread
From: Daniel Hartwig @ 2012-01-17 3:31 UTC (permalink / raw)
To: Aleix Conchillo Flaqué; +Cc: 10491
On 17 January 2012 02:57, Aleix Conchillo Flaqué <aconchillo@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
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#10491: unread-char and eof
2012-01-17 3:31 ` Daniel Hartwig
@ 2012-01-18 0:57 ` Aleix Conchillo Flaqué
2012-01-18 1:07 ` Daniel Hartwig
0 siblings, 1 reply; 6+ messages in thread
From: Aleix Conchillo Flaqué @ 2012-01-18 0:57 UTC (permalink / raw)
To: Daniel Hartwig; +Cc: 10491
On Mon, Jan 16, 2012 at 7:31 PM, Daniel Hartwig <mandyke@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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#10491: unread-char and eof
2012-01-18 0:57 ` Aleix Conchillo Flaqué
@ 2012-01-18 1:07 ` Daniel Hartwig
0 siblings, 0 replies; 6+ messages in thread
From: Daniel Hartwig @ 2012-01-18 1:07 UTC (permalink / raw)
To: 10491-done
On 18 January 2012 08:57, Aleix Conchillo Flaqué <aconchillo@gmail.com> wrote:
> On Mon, Jan 16, 2012 at 7:31 PM, Daniel Hartwig <mandyke@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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-01-18 1:07 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-01-12 20:14 bug#10491: unread-char and eof Aleix Conchillo Flaqué
2012-01-13 10:34 ` Daniel Hartwig
2012-01-16 18:57 ` Aleix Conchillo Flaqué
2012-01-17 3:31 ` Daniel Hartwig
2012-01-18 0:57 ` Aleix Conchillo Flaqué
2012-01-18 1:07 ` Daniel Hartwig
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).