[Q21.5] Add support for non-ISO2022 8 bit fixed-width coding-systems.

[Stephen J. Turnbull]

Aidan Kehoe writes:

 > Not these. Conceptually, to encode a character, these coding systems convert
 > the character to Unicode, and then do a hash lookup of the UCS code -> 
 > octets on disk table. So:
 >
 >   (encode-coding-string (make-char 'japanese-jisx0208 39 107) 'koi8-r) 
 > 
 > does the right thing. 

And what does

     (encode-coding-string (make-char 'japanese-jisx0208 48 108) 'koi8-r)

do?  Is there a reason why this technique should be restricted to
coding systems currently implemented in CCL, or could/should we
replace all ISO 8859 coding systems with this stuff?

 > These coding systems are much faster than that implies.

I don't think it's worth worrying about speed of coding systems until
somebody complains.  AFAIK nobody's complained about the *speed* of
mule-ucs, so I doubt they'll complain about this either.

 >  > If you just mean you're making this distinction properly, hurray!  But we
 >  > should avoid polymorphism in these functions if at all possible.
 > 
 > It’s not possible. 

In software, anything's possible.  What it sounds like you're saying
is that you're spending time and effort on a subsystem that is so
broken it needs mercy-killing.  Is that a good idea?