Oberon ? has String library/s ?

[n***@gmail.com]

Re. debate about Oberon & string libraries:
for me the BIG plus of ETHO is the HumanComputerInterface,
which no one will discuss; perhaps because cognition/psychology
is too fuzzy.
Here's the detailed log of a LEO [ETH Oberon (2.4.3) for Linux x86]
real task. I want to find and list the procedures of the <string module>
which I've previously seen and perhaps even used.

=> find the source-code ; much text pasted here is merely kliked in-situ.
-> System.Directory *tring*od
== 0 Files 0 Directories

=> OK, see if the object code exists
-> System.Directory *tring*bj
== /mnt/hdc6/home/oberon/obj/Strings.Obj

=> OK, what's that function which sees into the *.Obj
== perhps I can recognise it on the <menu>
the popup menu shows Watson.ShowDef ^
-> let's try that on Strings.Obj
== DEFINITION Strings; (* portable *)

(* Strings is a utility module that provides procedures to manipulate strings.
Note: All strings MUST be 0X terminated. *)

CONST
CR = 0DX; (* the Oberon end of line character *)
Tab = 09X; (* the horizontal tab character *)
LF = 0AX; (* the UNIX end of line character *)

VAR
isAlpha: ARRAY 256 OF BOOLEAN; (* all letters in the oberon charset *)
ISOToOberon, OberonToISO: ARRAY 256 OF CHAR; (* Translation tables for iso-8859-1 to oberon ascii code. *)
CRLF: ARRAY 4 OF CHAR; (* end of line "string" used by MS-DOS and most TCP protocols *)

(* Length of str. *)
PROCEDURE Length (VAR (* in *)str: ARRAY OF CHAR): LONGINT;

(* Append this to to. *)
PROCEDURE Append (VAR (* in/out *)to: ARRAY OF CHAR; this: ARRAY OF CHAR
...
=> let's try some tricks to extract the "PROCEDURE" <ID> line from the rather big
Strings.Def textFame supplied.
RX.Tool which was a bit problematic had facilities.
We don't 'type' RX.Tool. We just klik the text already existing *HERE*,
and klik Grep which gives:--
The Grep Command

RX.Grep ( filename | "*" ) [option] RegExpr
Searches in the file filename or the marked text for the regular expression
RegExpr. The output will be diplayed in a seperate text viewer.

option = "\" { "c" | "i" }.

Options :

c : Ignores the case of the letters
i : Invert the search and displays only the lines that do not match
---------
=> Let's try
-> RX.Grep * PROCEDURE
== that failed. I've been using too much *nix. Let's try:
-> RX.Grep * "PROCEDURE "
== which gives a TextFrame starting thus:--
PROCEDURE Length (VAR (* in *)str: ARRAY OF CHAR): LONGINT;
PROCEDURE Append (VAR (* in/out *)to: ARRAY OF CHAR; this: ARRAY OF CHAR);
PROCEDURE AppendCh (VAR (* in/out *)to: ARRAY OF CHAR; this: CHAR);
and I notice the <problematic> char in the first 2 lines.
But actually, I want to <count> the number of PROCs provided by Strings.Mod
Vaguely I remember there's a *.Tool which <counts lines>?
-> Find.Panel *.Tool ount
== give 5 tools & I recognise Miscellaneous.Tool which klik shows:-
Miscellaneous.CountLines ~ count the lines in a file
=> <mark> the oppropriate TextFrame &
-> Miscellaneous.CountLines ~
== Call error: Miscellaneous not found
So this module is missing from LEO. Let's see if the source exists.
-> System.Directory Miscellaneous. Mod == 0 Files 0 Directories
Perhaps I'll try to install it. But G.F. had a good reason not to?
OK, lets use LEO to get the answer via linux:
first save the appropriate TextFrame in *nix format, by just copying it to
/tmp/CountStrngMod and
-> System.Execute cat /tmp/CountStrngMod | wc -l
== 35 <-- functions provided by ETHO's String <library>
----------------- Now just send this very-same TextFrame to USEnet,
by: marking it & ipNews.Send *

PS. Has anyone achieved Gmail via ETHO.

--- start of oberon mail ---
S>Bhei1`0nDaFFinFg6CHjbY>FgjBSjFjl1AN0<P4842P2lY2EVEUYYeY5eUCM\^1H3H0O@;@1nP
***@D`0B04P2`6`0nPOR141A13h3b;2`7<0PdP0l10n2200b32`70HC8003P=P00<0V520`0hN00
***@B0:0a57hC5KIU3UY;WjHM3`8`0Ho3P2l1GJ0TP?E\UE>4VReUCM<P183X0<8P80D:PKP5lY
R]<`djbY>6`7D3D0Z260m05P[Q1T080h5`7<P10b9B`0l12P381X0<0<P?X10=08980EY3\QB]\^
4TT]\R=\d]\P<\Rm]eU^PlYR]<4TV4TcU^b=]^m\PT]YE\b=\b=]UM^j\QPd\_E^P\]U5Td5]U5T
2=Y75T`U]eM^Pl]V5T5UZ8mYP<]c5Td5]U9B[KK3[K7jKK;L[;M;[LCZKYKIU[I3kH;;;K88_;JC
kHA;8MkK1iKMKI1iMC;KI;89KJWkH[kLWk>19L;[LAKHQkL1YH;kH3KMWKI1iHOkIMKJYKJO[KO9
LWKN7;JO;***@JfjZGmVGGf@TFFiFfC>***@BGd8I;;M3KJIKI9;8IkK?;8O[I6
***@bdRnD@^eRBET2bW:68:UY;YY;WI:1YIOS<=]^]^h5Th5Wf\[=D^U=\\5Td=\cM]^4T95Tg=\^U
^PT^_5TV=]^U\P<\^U\PT]YM^d5Td5]U9LUkK7KI9KMUKIW;8OSd5]U9?W;MU3ffgBfjbfbjc6NG
dVfa4T9mTf]\P4^b]\f=]_]^cU]i5Tc]\Ue]P<\^U<QKIU3\\f]\^5TeM^UU\^\Q=\Wn4TV=]^A@
BGdhLOKMUkH;K;7kK9KI1i>1IK[kHA;8YKIa;M19L3kLYKI9;8AKIUKI1IJW;8KKIUKIIKN1iJIK
JGKI9;8C[KKiLC;M[[;KH;m98WJNW;M;KKM9AC[L;kHYkKUKN1Y:Y[LC[KZbgBf6fcN2BH2BSVFf
***@H2BRVFiF6<]UM^=\Qmd7OjBI98WKI;;8C[I19MAS_E\Z]\SU^PL\_U\UIIaKJW;MWK3KY?1
1F60Ocl0XHEK3kI?1i;K[KYk;A;I7[=O9JOKK;k;O[H`GnFaZfG>Ej:gdhLMiC5[JKH3k1hMAKHY
k9W;8Yc`***@JfjjfaBgdnFg2bkRfd`iFVc5TYe]dm]PT^X]<EY;OZHEcN8L;[L2gi2bT2ba6Fg2B
iFfanfcjVc]\P<]d5T_e]PT^XANffbjfjjc62BjR6QkKQKMQ;8KKIMC@>Gdnfk>***@Ne`BginFgjb
YRfgTXUe\P4TN]QP\Un4T\]\dmTc9MUKN19MAKHl=>Ej:gd009JA=JBMJBYJBOZC1iDY3LW94UZ4
T`m]bU^QE\\]\PDUY\Q=4UZ4TCU>@@Vfi<\P\^d=]\=]d=_P\]_U<4Td5=4^bm]f=]T]\c5T`E^_
M<`iT>1IK3[KC;L[;K3;M;;8W;MU3jb6V`***@6DfbF@>Gj:74T=]ZCUZPD\U5T`4[PT>U
KKC[K3;M;;IM98EI:K`4>dWjdYBe6V`4>DY4Tm4T`TXHMWP4UZ4Td5=***@bfdj
fb2baRf`:g`>FjFFi2BEVR9<QD=\R=PP\WP4Vi4[k4TX04]_E^YE__e]d=\\5TdYH1iHAKH00IZA
***@aj>11`***@FFgB6000\1]***@UJ3CH2CkL3:KQ;***@c:8UI=]98OZA1Y
@OjCIJA3ZCg98AY:***@bfbBGjFFi>***@VFg2BjR6Ocb:71iHASc]\d5TZ<U=<1CjDO:EOkC5KI
***@ZnfT>***@M2bP:***@AJ@Uj>19:TZb=\^M^\=\d=]_Aj6FabVc5TVm]bIJWkKK9>aI=
cI;S98YkK1iK5KI883kL7KJC;87kK9CG2BEV2>T<eX6DWP<XB1Y98OZA110;[K0C35iLY[LX81IM
WSPD\i5T=MZ]TX?MZP<\^U\P\]_M^***@5T`E>YkK7kKIkL1Y:CI3K8:TYUe]WU^X5T_e<W;M
U[;1Y:***@bdbj6N@@RB[***@VVPD5W;MU[>***@P?eXP0CY>19COZC?JB
M:EgI3K8:EaP2GhFFgBVd5]YM^PT>***@ZbDf00H@Q;L8219:]***@0nbgFGj2BET^_EWP<XB10^
Sd5]YY>***@00K88MY;MI3kY?19Kl4Pcm]]]\PT^b=]SM]c5Tdm]P\\hU^b=\SU^PT>;CA2EYndQ0
598iIB9Z?19KC3=[LOKK19MAKI:g`BGdFFi2BaVfcf`YBGiV6W[;9JI=;8YKIaCS6ffFF@>gj2Gh
bfdFFbjb6:E\***@NWYQg=\c5TQ5TR=]d5T`iK5;K;KK3;MCkH19J3;I1YI3kHC;KC;MCKI
W[;KhE;;89kKMk9Y;8?9Mc;L;k91YDaZ;Y2M98_JI1YJ[kLY;8G;***@BGdFVd]\h983;KUKI3;I
c;8;;NHJMkI1Y:AJAUJAE9;KHHM;I1iJI3?ZL;;L1iMA3NfdJgb>***@ZRfb2bS:***@OKKKK
HM;IKH3U:FMiAUKIQCD2BcVFfFFg6ffFVl5TRDUR4TY4TKm]`U^Ym]^][PDZUm\55_`E^=LZU=\b
M\X]\***@cVFf4TVQ^1O[L19MAS]=\bM]UU\PT^U5?Jfg:WdQb]\W]^\=\b5TU5_`E^UM^c=]
_e]=DZUm\5Q^4TD5]U5T_]^d5^eU^Pl^YU=:fbT\Y5^\=\i]\T5TYe]P<\PL^U5^UE^QU^U5Td1]
KJ;kM;[LMI3KH2O;LYKJ<Qm4TRT[R4Tk5TRL\R4Tl5TR<]R4TmeU=\Q?5>hL1Y>KH3ChHCX>1IB?
[KO[L;kL1AdhH3kL;;8O[I19M8K;;MY3KH2CK2e98CZK]KIU;M19MASc]\QE>2b`j69KJ2Gf6fl>
***@nFgbfl2BjR6IKJMci223STm]Pd]_U^P\]QU^S5]=\U]\U]0f`N8C;;M?1US=\Un4TB5[^l8X:1
9DUjC724T=\Wm8MAKHd\Q=]\]<MaTNBkXH;KIM;8[***@bdb0DW=\Un
00:BX:505I3kI?1iMPW11IHBebRGjJDi6ffFVcU^QE^d=]^m<Rfj>GMf2C8D08C00PPD5W3XD440
C10<***@E:06400h;0PB10^3V600<Uk\Q94:00LXX=QP4UF=800000g1`QR4CQQe=1IB1YKO;MCkH;
;8Y;J;CN2GinV\1dWPL\***@VFg2Bj@cD^cU^PDVPT]YQ^\Q2]^dIH7;M[KHI;Kc;;1IB1iMP_9?7
kK[***@B7jfjfFaFFi2bgJF@2EYhL19LUCkHI9;85SCU^b1fdgBf6Je`***@VD@:gbffbf
FaF6Y;J:gbN23;8EY;YjKO;K118?7kKhL19KC[KdWo\Q]d7=JJM;IM9D3[K;;K198EY;Y22bgFGg
***@f`NfSW=]f98[Q_m=WCC2bT2BiL<?3\YYM^S]\\U]Qe]Um]eM^^TZ_m=1iMP[U=L^Xm=W[>KI3
KJJWkH0`Qnfj8CC[K;***@jg4>fgFGg4Td5=19KPYa`d\YU=KH?mANff`:Wn4Td5=nFh2GinFh:gd6
***@BebXAPV4T=\***@V0mK3kI?>d`bFf2bb:***@fdd001YKOC@JfgFGgBf6>eg2
BjR61IKOcj`d>***@bdbPc]\U548JL^_]^bM<1IIa3W[;KH;maY`b00fdd0
0M98KjK9;8kI?19<PcQ41HJ;kL2eb:Gd66VdCbFf2Bj:***@VFg>Gj6FfbVYU^^4T2]^d5T7
eU6eUP4]QU\P<\Pl\_m]T5Tb]\QM^_e]Pd]_U>YkKoI3OjBI98IKI>***@FgiFF@bdR4Tdm]Pl\UU^
PT^Xa`jfiNgb:***@Jgd6F@bfd\>eI3=KJUkLL^Qe^U5Td5=4^`E^_ad00HJM;***@Jfg:gf6Fj
bB@:flD]eQS9LcKJMkI1IJY;8YkK1I3O9MK;***@OKMMcYBGijfcfdgBF@6FgH3KY?0\Xh]\S]^d
]\PL<Y;8O9MK;L008O1iM7;8K9KKH?***@2BNfbF2BcFGg`***@h:Wfab0;:EAbC>G@>Ej:gd88i
9KC[HHNmI3KI;KI;002BWnfk2BeFgihL;[K9;8Y;JCSf]\b=_]L^Q]]U5TD]<J48M\ZC]X^]\dUU
=D\iEWP\]QE>C[K?cdX91IJQ[C;kMW[;WJIMSZ\Q=4ZCeUP4YQM^P<\^=__e]U5TQM\X=]Ue^UU\
PlX]=\YU]Pd^Y=<;:EdU=Lk2=Y5EZ8>26j8H2^B84P>***@0fK82PY72Fa8X>***@06f8
***@0X2ZPoooDP14Pooo3eYQ]=1X07ZD80mP080D10<***@0\380D10<008C=:0180:R0
401P:0P100CkL3:K80X9401P:0P100CjDO:***@0X20H00`W:fb:***@0X20H00
`***@06240Z00600<X`5^U9I1`0TZU5??JH9kI;;MW[;***@O[KY[
LO;***@0%

[y***@z505.com]

Post by n***@gmail.com
== 35 <-- functions provided by ETHO's String <library>

I think this misses the point. One can write a string library in Standard Pascal or plain C and offer 35 functions (procedures), or even 3500 procedures to work with strings. This doesn't mean that all of a sudden the strings become useful in standard pascal just because a library is written. No matter how many libraries you write in plain C for example, doesn't improve the string system in C because it's broken from the beginning (as with standard pascal). The only way to get a string system working in C that doesn't require all sorts of memory allocation, is to abuse the preprocessor and reinvent C++ or something like it. In standard pascal you could write 3500 string procedures but that doesn't change the fact that you were limited to 255 characters and working around this turned into a "vicious circle" that never solved the problem.

So in Oberon we don't have 255 limit strings any more, nor do we have just plain C pointers to chars - but we have very similar limits in place where "writing a library" doesn't solve the problem. It's like saying standard pascal doesn't need a module system, because you can just write a library at the bottom of your pascal program. The compiler magic has to implement a module system. The compiler magic has to deal with strings - Even Java's string libraries still make use of compiler magic for the strings to work the way they do. Niklaus Wirth is against compiler magic tricks, but is he really? He implemented modules when a minimalist language doesn't need modules - standard pascal got away without modules... oberon gets away without a string? I don't think so. Just say no to "array of char" and "pointer to array of char". It's almost as bad as plain C, almost as bad as standard pascal, but not quite. In fact since plain C probably has some string libraries out there that make C strings easier to use, oberon might be in worse shape than plain C when it comes to strings.

The philosophy of defining your string length ahead of time, such as array of char (1024) is naive, because often strings will be used in situations where the developer made a big design up front mistake, and the user wants string (2048) in length. So what do the oberon programmers argue: whelp, you can always use a pointer to array of char and not define any length. Oh yes, how convenient - like plain C - C stands for cave men. It's like someone arguing that we don't need modules, we will just use module_like_this underscores in plain C where the module_ prefix emulates a module system. No compiler magic required! We've simplified the language by removing modules and not implementing them.

The people who start using strings in oberon (that don't exist) will quickly run off to Delphi, FPC, Go Language, python, Haskell, Ruby, PHP, and oberon will fade away into academic obscurity. Actually, even academics will refuse to use oberon in most institutions. Indeed array of char (1024) is useful when you know the exact length of a string, like for an embedded system where memory is tight and you have certain constraints in place ... But in the real world that isn't embedded but exists on the desktop and web servers, almost no one wants to define array of char (1024) or array of char (8) for 95 percent of all situations. It's useful for once in a while. And of course the oberon programmer will argue: but you don't HAVE to define the length! just use pointer to array of char! Using a pointer , for strings, is like using a GOTO statement to do a while loop. We aren't Cave Men. This isn't plain C. It's called a string. Python has it, Delphi has it, Java has it, FPC has it, PHP has it, Ruby has it.

The oberon programmer will then argue: just write a library! java is a library! No it is not. Java is BOTH a library implementation, plus compiler magic, not just a library.

So the oberon programmer may finally give up and say "modify the compiler to suit your needs! Component Pascal blackbox implemented a different string system!"

Ah ha! so we end up with 6 different versions of oberon, or maybe 65 versions of oberon - this was the problem with Standard Pascal which turned into 65 different versions of pascal... GNU pascal, Freepascal, Delphi, Turbo Pascal, Microsoft Pascal (this was short lived), Extended Pascal, Object Pascal, Apple Pascal, and a million others. Most of these "pascal"s try to fix standard pascals string problem, and add modules. Oberon has implemented the modules, but still gets strings wrong. History repeats itself: oberon is not popular because it didn't get strings right. That's one reason, not the only reason.

There is another issue with strings which is unicode, which increases complexity further and is terrible for teaching programming - it' so much easier to just ignore unicode and deal with plain english strings. But enforcing english onto people is like a sort of racism, and everyone wants to have their 5 million different unicode characters. Go Language tries to deal with unicode with getting rid of "char". Haven't used Go enough to make further comment.

Z505 Software
Critic of Programming Languages
Are there Ansistrings in Quiche

[Pascal J. Bourguignon]

Post by y***@z505.com

Post by n***@gmail.com
== 35 <-- functions provided by ETHO's String <library>

I think this misses the point. One can write a string library in
Standard Pascal or plain C and offer 35 functions (procedures), or
even 3500 procedures to work with strings. This doesn't mean that all
of a sudden the strings become useful in standard pascal just because
a library is written. No matter how many libraries you write in plain
C for example, doesn't improve the string system in C because it's
broken from the beginning (as with standard pascal). The only way to
get a string system working in C that doesn't require all sorts of
memory allocation, is to abuse the preprocessor and reinvent C++ or
something like it. In standard pascal you could write 3500 string
procedures but that doesn't change the fact that you were limited to
255 characters and working around this turned into a "vicious circle"
that never solved the problem.
So in Oberon we don't have 255 limit strings any more, nor do we have
just plain C pointers to chars - but we have very similar limits in
place where "writing a library" doesn't solve the problem. It's like
saying standard pascal doesn't need a module system, because you can
just write a library at the bottom of your pascal program. The
compiler magic has to implement a module system. The compiler magic
has to deal with strings - Even Java's string libraries still make use
of compiler magic for the strings to work the way they do. Niklaus
Wirth is against compiler magic tricks, but is he really? He
implemented modules when a minimalist language doesn't need modules -
standard pascal got away without modules... oberon gets away without a
string? I don't think so. Just say no to "array of char" and "pointer
to array of char". It's almost as bad as plain C, almost as bad as
standard pascal, but not quite. In fact since plain C probably has
some string libraries out there that make C strings easier to use,
oberon might be in worse shape than plain C when it comes to strings.

You didn't get the point that by relegating the definition of a data
structure like strings to a library, this allows you to define a string
abstraction with all the features and good properties you would want.

The language in this case doesn't impose on you a flawed definition.

For example, in Oberon 07, strings are defined as array of CHAR, and
CHAR are "characters in a standard character set"; furthermore, there
are functions CHR(INTEGER)->CHAR and ORD(CHAR)->INTEGER, but there's no
definition for INTEGER other than "the integers". Assuming a common
implementation choice of having INTEGER be a finite set of integers (eg
[-2^31,2^31-1] or [-2^63,2^63-1], then CHAR CANNOT represent the UNICODE
character set. Therefore in such an Oberon 07 implementation you CANNOT
represent UNICODE strings in Oberon source programs as string literals.

In such a situation you DEFINITELY will want to use a library to deal
with strings of unicode characters (including composed characters with
variable number of code-points).

Post by y***@z505.com
The philosophy of defining your string length ahead of time, such as
array of char (1024) is naive, because often strings will be used in
situations where the developer made a big design up front mistake, and
the user wants string (2048) in length. So what do the oberon
programmers argue: whelp, you can always use a pointer to array of
char and not define any length. Oh yes, how convenient - like plain C
- C stands for cave men. It's like someone arguing that we don't need
modules, we will just use module_like_this underscores in plain C
where the module_ prefix emulates a module system. No compiler magic
required! We've simplified the language by removing modules and not
implementing them.

And here you are confusing two different things.

String is a specific abstraction.
Module is an abstration building tool. It's a meta-abstraction!

You want to include in a programming language abstraction building
tools: ways to define functions (= functional abstractions), ways to
define type (= data abstractions), ways to compose abstractions into
higher level abstractions (= modules), ways to define lexical
abstractions (= lisp reader macros), ways to define syntactic
abstractions (= lisp macros), ways to define metalinguistic abstractions
(= lisp macros too).

You may include some concrete abstractions into your language, as long
as they're useful to define user abstractions, so you can have symbols
and lists in lisp, but mostly all the rest is useless, since it can be
redefined by user code. (And even, there's no list abstraction in lisp,
it's actually the lower level notion of cons cell that's abused; there's
no list in lisp!).

And indeed, we notice that it is all those useless concrete abstraction
included in the language that are friction points in each language.

Post by y***@z505.com
The people who start using strings in oberon (that don't exist) will
quickly run off to Delphi, FPC, Go Language, python, Haskell, Ruby,
PHP, and oberon will fade away into academic obscurity.

Notice that you cannot include into the language a good modern string
abstraction, without:

1- updating your language specification every year, along with the
updates of the unicode standard.

2- making your programming language specification very complex ( have
you seen the size of the unicode standard!?).

Post by y***@z505.com
Indeed array of char (1024) is useful when you know the exact length
of a string, like for an embedded system where memory is tight and you
have certain constraints in place ...

Vectors of variable or changing size are obviously more complex to
manage, and this can be done nicely only if you accept to add a garbage
collector. Notice how all the languages you mentionned above (apart
from the older Delphi and FPC) include garbage collectors.

Post by y***@z505.com
And of course the oberon
programmer will argue: but you don't HAVE to define the length! just
use pointer to array of char!

No, this is not the argument. The argument is: use a library!

Post by y***@z505.com
The oberon programmer will then argue: just write a library! java is a
library! No it is not. Java is BOTH a library implementation, plus
compiler magic, not just a library.

The advantage of a library, (instead of a "standard" library), is that
it's a modularity point. If you're implementing a desktop application
for a multi-cultural user, you will choose the unicode string library;
but if you're implementing an embedded garage door opener, you will use
a simpler fixed-length-ASCII-string library if at all.

Post by y***@z505.com
So the oberon programmer may finally give up and say "modify the
compiler to suit your needs! Component Pascal blackbox implemented a
different string system!"
Ah ha! so we end up with 6 different versions of oberon, or maybe 65
versions of oberon - this was the problem with Standard Pascal which
turned into 65 different versions of pascal... GNU pascal, Freepascal,
Delphi, Turbo Pascal, Microsoft Pascal (this was short lived),
Extended Pascal, Object Pascal, Apple Pascal, and a million
others. Most of these "pascal"s try to fix standard pascals string
problem, and add modules. Oberon has implemented the modules, but
still gets strings wrong. History repeats itself: oberon is not
popular because it didn't get strings right. That's one reason, not
the only reason.

Yes. This is the problem with languages that don't have lexical,
syntactic, and metalinguistic abtraction building tools. The only way
you have to climb this ladder, is to implement pre-processors or whole
new compilers. Instead, you could integrate into the language what lisp
has had since the 60s.

Post by y***@z505.com
Go Language tries to deal with unicode with getting rid of
"char". Haven't used Go enough to make further comment.

This is not really the problem. I notice that CHAR is defined half
correctly in Oberon 07. If you would just remove ORD and CHR, then as
an opaque data type it can abstract multiple unicode codepoints, what a
user would call a character. Instead you could have a library call to
get the variable number of code points: Unicode.getCodepoints(char,cps,cp_count).


On the other hand, for source code, even when the language specification
allows unicode, it's very rare to take advantage of it; certainly not
for the identifiers or the comments, because either you're doing free
software and you want a world-wide audience of potential contributors,
and writing your comments (or worse, your identifiers) in German,
French, or Chinese is not the best way to gather a big number of
contributors; or you're doing privative software, and your employer
will want to outsource some development to some cheap alien country, or
will want to exit selling his company to some US company, and in both
cases, he will want the sources to be in English too. This leaves only
a very infrequent and improbable situation for source code written in
another language. This is also the reason why there's no national
programming language either, despite some rather successful experiments
before the advent of the Internet (or even recently). It may be a
problem only for the youngests newbies: you have to learn some English
before learning to program, which is most unfortunate.