Re: raw-byte and char-table

[Kenichi Handa]

In article <address@hidden>, MON KEY <address@hidden> writes:

> > I'm not arguing that the syntax is cryptic.  What I want to
> > say is that it is difficult for one who reads the code to
> > understand what #x3FFFA0 means.

> So the syntax aren't the problem its their semantic denotation.

Sorry, but I can't parse the above sentence.  Could you
please paraphrase it?

> Regardless, right now it is all confusing (esp. for those of us less
> inclined to differentiating the multibyte/unibyte distinction).

I agree that the handling of raw-byte is very confusing.
The base is, I think, because we represent a character by an
integer value, and we must introduce character-object to
solve that confusion.  Unfortunately, it requires a huge
amount of work.  Until someone volunteer that work, we must
live with the current infrastructure of Emacs.

>>> This signals an error:
>>>  (unibyte-char-to-multibyte
>>>   (unibyte-char-to-multibyte 160))
> >
> > Yes, but is it a problem?

> I would urge that it is a problem wherever the numerical denotation
> has no visible/nameable/printable corollary.

> Why should it be allowed to be problem if it can be avoided?

Conceptually we have "byte", "integer", and "character", and
#x3FFFA0 is both an integer and a character representing
byte 160.

Perhaps we should not call "byte" as "unibyte char", rename
the above funciton to "byte-to-char", and document it as:

(byte-to-char BYTE)
Convert the byte BYTE to a character representing BYTE.

Then it's clear that (byte-to-char (byte-to-char BYTE))
signals an error.

Likewise multibyte-char-to-unibyte => char-to-byte:

(char-to-byte CH)
Convert the character CH to a byte.
If the character does not represent a byte, return -1.


By the way, we also have decode-char.

(decode-char 'eight-bit 160) => #x3FFFA0

---
Kenichi Handa
address@hidden