[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Encodings.

This page is part of the web mail archives of SRFI 52 from before July 7th, 2015. The new archives for SRFI 52 contain all messages, not just those from before July 7th, 2015.

On Thu, 12 Feb 2004, Paul Schlie wrote:

>Hi Robby,
>Sorry, but unfortunately I'm missing your point; as it seems to me that
>the only potential ambiguity that exists by continuing to restrict the
>composition of scheme code to using a "truly portable" character subset
>as exists today, is a formal specification of how to express/display
>characters and strings composed of characters beyond scheme's portable
>character set. (as scheme programs utilizing portable characters already
>can be converted/displayed/editable on most known present/future hosts).

This is actually a very good point.

If we agree on a convention for writing and displaying these extended
characters into identifiers, character constants, and strings using the
portable character set, then we are able to write portable code using
them.  If a particular implementation displays them as literal glyphs
instead, or allows users with a particular keyboard to type them as literal
glyphs, or is able to accept program text where they are "directly present"
in the code rather than displayed using alternate means, I'd say it's a win.

I'd suggest therefore a means of extending the "named" characters -- R5RS
gives us #\space and #\newline but we ought to be able to add characters
to the named set using some kind of binding construct, and thereafter
refer to them by name in strings, character constants, and identifiers.