Re: char-set-contains? and #<eof>

Re: char-set-contains? and #<eof>

[Andy Wingo]

Hi,

[keeping the list cc'd]

On Sun 30 May 2010 22:24, No Itisnt <theseaisinhere@gmail.com> writes:

>> For example, what would you have Guile do here:
>>
>>  (even? #f) => ?
>>  (char-whitespace? 42) => ?
>
> I'd have it raise an error.
>
>>> The reason it bothers me is because it makes it cumbersome to deal
>>> with input from a port.
>>
>> True; but it's just how it is, I think. The EOF object is not a
>> character.
>
> But it is returned by read-char, unlike the other examples.

A fair point. The consistent thing to do would be to make all char-foo?
predicates return #f for the EOF object (char<? and friends excluded of
course). Ludovic what do you think?

One point against such a change is that such programs would not be
portable -- at least PLT Scheme^H^HRacket raises errors in these
situations, as Guile does. But OTOH Racket folks are not themselves
against changes where things make sense, so perhaps this is not a strong
argument.

Andy
-- 
http://wingolog.org/

Re: char-set-contains? and #<eof>

[Ludovic Courtès]

Hi,

Andy Wingo <wingo@pobox.com> writes:

> On Sun 30 May 2010 22:24, No Itisnt <theseaisinhere@gmail.com> writes:
>
>>> For example, what would you have Guile do here:
>>>
>>>  (even? #f) => ?
>>>  (char-whitespace? 42) => ?
>>
>> I'd have it raise an error.
>>
>>>> The reason it bothers me is because it makes it cumbersome to deal
>>>> with input from a port.
>>>
>>> True; but it's just how it is, I think. The EOF object is not a
>>> character.
>>
>> But it is returned by read-char, unlike the other examples.
>
> A fair point. The consistent thing to do would be to make all char-foo?
> predicates return #f for the EOF object (char<? and friends excluded of
> course). Ludovic what do you think?

I don’t see how R5RS or SRFI-14 would allow this.  For instance R5RS has
this:

 -- procedure: char? obj
     Returns #t if OBJ is a character, otherwise returns #f.

and this:

 -- procedure: eof-object? obj
     Returns #t if OBJ is an end of file object, otherwise returns #f.
     The precise set of end of file objects will vary among
     implementations, but in any case no end of file object will ever
     be an object that can be read in using `read'.

So EOF and char are clearly disjoint types.

Am I missing something?

Thanks,
Ludo’.

Re: char-set-contains? and #<eof>

[No Itisnt]

On Mon, May 31, 2010 at 3:39 AM, Andy Wingo <wingo@pobox.com> wrote:
> Hi,
>
> [keeping the list cc'd]

I apologize ; I keep doing that because I'm using this webmail
interface. I really need to set up my email properly one of these
days.

Re: char-set-contains? and #<eof>

[Andy Wingo]

On Mon 31 May 2010 18:27, ludo@gnu.org (Ludovic Courtès) writes:

> Andy Wingo <wingo@pobox.com> writes:
>
>> On Sun 30 May 2010 22:24, No Itisnt <theseaisinhere@gmail.com> writes:
>>
>>>>> The reason it bothers me is because it makes it cumbersome to deal
>>>>> with input from a port.
>>>>
>>>> True; but it's just how it is, I think. The EOF object is not a
>>>> character.
>>>
>>> But it is returned by read-char, unlike the other examples.
>>
>> A fair point. The consistent thing to do would be to make all char-foo?
>> predicates return #f for the EOF object (char<? and friends excluded of
>> course). Ludovic what do you think?
>
> EOF and char are clearly disjoint types.

No argument there :)

The point is that the return type of read-char is not "Char"; it is
either a char or EOF.

The proposal is to make char predicates return #f for EOF as well,
making them accept the same type as read-char returns.

> I don’t see how R5RS or SRFI-14 would allow this

It does seem to be permissible; not normal, but it could be useful. More
useful than raising an error, I would imagine...

Cheers,

Andy
-- 
http://wingolog.org/