On 18 January 2012 08:57, Aleix Conchillo Flaqué wrote:
> On Mon, Jan 16, 2012 at 7:31 PM, Daniel Hartwig 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
On Mon, Jan 16, 2012 at 7:31 PM, Daniel Hartwig 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
On 17 January 2012 02:57, Aleix Conchillo Flaqué 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 ar
On Fri, Jan 13, 2012 at 2:34 AM, Daniel Hartwig 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 do
On 13 January 2012 04:14, Aleix Conchillo Flaqué 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 sho
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.
