Re: ASCII character classification
Lassi Kortela 22 Nov 2019 19:24 UTC
> (ascii-graphic? char) -- all non-control ascii chars, including space.
> no other whitespace characters.
>
> This is just the negation of ascii-control?, and traditionally Scheme
> doesn't do these [...] I would propose simply dropping it
lol, you're right. Let's drop it. Perfect.
The control character procedures can be control->graphic and
graphic->control, which is standard terminology.
> (ascii-space-or-tab? char) -- does what it says on the tin. alternative
> names: `ascii-blank?` (too ambiguous) and
> `ascii-horizontal-whitespace?`
> (clear, but too long).
>
> In traditional RFC terminology this is "hwsp", but that may be too
> obscure now. I guess space-or-tab is as good as we can get.
I've sometimes used "horz-white" but that's also obscure. "horz-space"
would be even more obscure.
Instead of `ascii-space-or-tab?` it could be `ascii-space/tab?`.
> SRFI 14 (which may or may not be replaced for R7RS-large)
>
> It won't be replaced unless someone else makes a motion to that effect
> and it's voted in. The only real problem with it is the rules for
> assigning Unicode characters to standard character sets. I've written a
> post-implementation note that points to a detailed explanation: see
> <https://github.com/johnwcowan/srfi-14>.
I read the new commits. Are you referring to the problem with which
version of Unicode to follow?