John Cowan wrote:
> I basically agree with what Tom Lord says about ports, and I would agree
> with what he says about characters and strings if he didn't want to call
> them "characters" and "strings".
>
> That is, it's perfectly reasonable to have communicable-atoms and finite
> sequences of communicable-atoms, and to communicate them using ports of
> a type neither binary nor textual.
>
> But I don't think R6RS needs to standardize those things.
>
Which seems to me a regression from R5 in which the requirements
for the CHAR type are specified with a light enough touch that,
de facto, almost exactly the "commuinicable-atoms" we're talking about.
This isn't just a theoretical question.
Example: I've used the CHAR type in a traditional lisp way: to
represent typed characters with "bucky bits" like
META-ALT-SUPER-X. I understand others have as well
and do you agree permitting at least /that/ would be a reasonable
compromise? If that example should be permitted that gives us at least
a loosening of the range restrictions.
Example: Scheme has been used quite a few times, successfully,
in embedded systems (such as controlling small robots). Such
applications often need a small footprint and don't need, for
example, large Unicode property tables. If that's permitted, that
gives us a shrinking of the mandatory character set.
The large changes I've proposed from R5 are that CHAR->INTEGER
/may/ be partial over the domain CHAR and that the ordering of
characters /may/ be a partial order.
The change to CHAR->INTEGER is nasty, in some respects.
For example, consider how it complicates the implementation
of a character property table.
Similarly, the partial order complicates applications such as
an associative table mapping arbitrary character strings to
arbitrary values.
I think strong arguments can be made for those two changes
anyway but, perhaps I should wait to first see if the questions
matter to the editors, etc.
-t
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.r6rs.org/pipermail/r6rs-discuss/attachments/20070316/8b848073/attachment.html
Received on Fri Mar 16 2007 - 17:54:40 UTC