[9fans] The cost of Runes in Lexi

[9fans] The cost of Runes in Lexi

[dbailey27]

Hey, all,
	I'm redesigning my tokenizer and preprocessor to use Runes,
and it got me to thinking... is it worth the time to interpret UTF
patterns besides Latin '0' -> '9' as integers? If one performs a
grep on /lib/unicode:
	grep '(digit|number)' /lib/unicode

it is obvious that more than a few languages will have disctinct
UTF patterns for digits. Is it desirable to interpret these values as
digits? I'm especially interested in the opinion of our Asian friends.

	In Japanese (and others?), integers are depicted by multiple
glyphs when written as Hiragana. However, are there single-glyph
Kanji that can be interpreted as an Integer when seen isolated from
other NAME class glyphs?

	Basically, this would allow for unicode known to equate to
digits to be interpreted as integers in expressions and assignments
throughout an ASM or C source file. Every unicode *not* known as
a digit would be interpreted as a NAME class character. Thus, one
could still properly program C source in Thai, Lao, etc, as long as
each reserved word was still in english.

	What are your thoughts?

Don (north_)

Re: [9fans] The cost of Runes in Lexi

[Douglas A. Gwyn]

dbailey27@ameritech.net wrote:
> ... is it worth the time to interpret UTF
> patterns besides Latin '0' -> '9' as integers? ...

Not really, at least not in the context of technical uses,
where everybody learned to use Arabic numerals.  Other
numeric glyphs can be thought of as ideographs; you have
to deal with them (unchanged) as part of text strings, but
you don't need to bog down parsers using an overly generous
implementation of isdigit().

Re: [9fans] The cost of Runes in Lexi

[dbailey27]

> you have
> to deal with them (unchanged) as part of text strings, but
> you don't need to bog down parsers using an overly generous
> implementation of isdigit().

How very cute.

Re: [9fans] The cost of Runes in Lexi

[dbailey27]

> How very cute.

I'm doing it anyway.