OT [Way OT]: Unicode Unification Objections

[Kevin Russell]

"Dennis E. Hamilton" wrote:

> Consider the following.  In Japanese texts, when a borrowed or employed
> Korean word is used, a desired practice is to render the Korean
> characters as different, even though some or all of them involve "the
> same character" common to both languages.  However, the iconography (or
> calligraphy) is commonly different.  This loses the ability to
> distinguish the linguistic use of the character, forcing material to be
> font-distinguished some how (e.g., give me the ones that look Korean,
> not the ones that look Japanese).  This means that the distinction can't
> be preserved in simple text.

The entire point of markup is that distinctions like this *shouldn't* be
preserved in simple text.

How a particular character should *look* is a question for presentation
glyphs, not for character encoding.  What kind of language a character
is used to represent (emphasis, quotations, foreign borrowings, titles,
proper names, sarcasm, etc.) is a question for markup, not for character
encoding.

A similar situation holds in almost every written language.  We often dump
Latin or French words into English text.  Even though they may be written
in the same alphabet, we usually want them to *look* different from
ordinary English words.  But nobody uses that fact to argue that Unicode 
should have handed out a separate code number to italic "e" than to plain
"e" -- or even that entirely disjoint sets of codes should be used for 
writing Latin, French, and English words.  (Actually, there probably were
people who argued these, but they were rightly ignored.)

Once you start mixing up glyph questions (what a character should look
like) and markup questions (what kind of language is the character being
used for) with character encoding questions, there's no logical place to
stop.  Soon the Unicode Consortium would be fielding requests like
"I want to be able to distinguish the Yamato pronunciation of the
'sun' character whispered with a Hokkaido accent and a lisp from
the Yamato pronunciation of the 'sun' character as muttered inaudibly
by someone from Okinawa who has a head-cold.  And I want to
do it with a character that looks like it was finger-painted in drippy
chartreuse water-colours by a five-year-old.  And it should be 23-point
bold, 'cause it will be in a title.  I suggest you assign me character
xDE4A921B."


>
> Unfortunately, the Greek alphabet and the APL alphabet (and apparently
> some other math symbol alphabets) *were* unified.  That is, a number of
> Greek-letter symbols were removed from any distinct APL character set,
> and only some APL-unique made-up symbols having Greek letters in them
> were retained as separate.  Unfortunately, the iconography of the Greek
> alphabet in Greek text is often enough different that those codes don't
> render appropriately with the other APL symbols when used in APL texts.
> Borrowing epsilon (for member) from the Greek character set in Unicode
> is not always what one wants to do when writing membership propositions
> in APL (and borrowing the alternative MEMBER OF symbol may not get you
> what you want either).  It's even more fun if you want to write APL
> programs and use Greek-language identifiers.  Something a CP4E teacher
> in a Greek school might strongly desire to do.  Get it?
>

What kind of sadist would try to teach a CP4E course using APL?!   
(And I say this fondly as someone who learned APL as my first 
computer language in high school.)

Actually, this is a very good point. But the problem is more with APL 
than with Unicode.  Every computer language needs a way to distinguish
characters used in literals from characters used in operators from
characters used as raw data (e.g., strings), and so on.  Usually the 
decisions made during syntax design will limit to programmer's freedom
to make up literal names. (Or to quote what I said at 90 decibels at 
2 a.m. two nights ago: "Why the **** can't I call that variable 'class' 
if I want to call it 'class'!)  Iverson's decisions during APL's syntax
design must have made perfect sense in 1960, but in hindsight they 
turned out to be extremely inconvenient.  If you want to extend APL 
to make it less inconvenient for your Greek teacher, you're either
going to have to redesign the language syntax from scratch (as Iverson 
did for J) or you could take the problematic APL characters and assign 
your own codes to them from Unicode's private use blocks.  That's what 
the private use blocks are for -- they let you and the four other people
in the universe who are going to use your Greek APL interpreter do what
you need to do, without bogging down the entire character standard.

-- Kevin Russell