On 5/22/06, Juan Jose Garcia Ripoll <lisp@...> wrote:
> On Mon, 2006-05-22 at 17:56 +0900, Brian Spilsbury wrote:
> > At the moment I've decided to not worry about scripts and just get
> > unicode strings working, with extended characters being locked down to
> > boring defaults for case conversion, the reader, etc.
> Well, one can easily build on top of this. I am busy right now fixing
> some compiler bugs, I am looking forward to your patch.
> > Currently I'm permitting unicode symbol names, since it looks like
> > that may require some policy decisions with respect to C identifiers.
Oops, that should be /not permitting/.
> "Weird" in the sense of not ANSI C characters are replaced by more
> standard ones (_, uppercase letters, etc) systematically when creating C
> names for functions. Is this what you mean?
Well, that isn't going to work for Korean, for example.
And it might not work well with symbols which are differentiated by
So, it might be necessary to develop a more general system of substitution.
> This use of #\\ breaks the standard and it might break other's people
> code. It should not be needed once we have streams reading UTF-8 and
> editors which understand it. However, I agree that this feature might be
> useful. What you want should be implemented as a separate reader macro,
> perhaps #u"....".