Email list hosting service & mailing list manager

ASCII character classification Lassi Kortela (22 Nov 2019 13:33 UTC)
Re: ASCII character classification John Cowan (22 Nov 2019 14:52 UTC)
Re: ASCII character classification Lassi Kortela (22 Nov 2019 19:24 UTC)
Re: ASCII character classification John Cowan (22 Nov 2019 19:33 UTC)
Re: ASCII character classification Lassi Kortela (28 Nov 2019 13:57 UTC)
Re: ASCII character classification John Cowan (28 Nov 2019 14:41 UTC)
Should ASCII procedures accept non-ASCII characters? Lassi Kortela (28 Nov 2019 15:00 UTC)
Re: Should ASCII procedures accept non-ASCII characters? Lassi Kortela (28 Nov 2019 15:08 UTC)
Re: ASCII character classification Lassi Kortela (29 Nov 2019 01:08 UTC)

Should ASCII procedures accept non-ASCII characters? Lassi Kortela 28 Nov 2019 15:00 UTC

> I took it to be part of the definition of these functions (other than
> ascii?) that it's an error to apply them to non-ASCII characters, but I
> see that's not actually true.  Perhaps it should be?  Consider that
> (number? 'foo) returns #f, but (even? 'foo) is an error.

It's deliberately allowed to apply the ASCII predicates to character
objects and integers representing non-ASCII codepoints. They just return
#f for non-ASCII characters.

This is intuitive, and allows people to write code like (string-every
ascii-upper-case? string) without having to do any other checks to the
string first.

Since ASCII characters and non-ASCII characters use the same concrete
type (Scheme characters or integers) I thought it's simplest if we
accept other characters.