On Sat, 19 Mar 2022, Raul Miller wrote:
> How can a programmer write a program to handle text if the language
> does not allow text to exist?
That is nonsense. Programming is all about representation. You might
as well say: how can a programmer write a program to handle graphs if
the language does not allow graphs to exist?
A problem, with this argument, is that programs *are* text.
Or, more specifically, we use text to represent programs.
Indeed. In a hypothetical version of j without first-class textual data,
an alternate representation would be needed to describe programs.
Note I do not think getting rid of text would be the _best_ thing. I
would rather improve it.
the unicode suite of standards defines quite a variety of ways of
representing unicode characters.
Unicode specifies precisely three representations (v14 ยง2.5): utf-32,
utf-16, and utf-8. Of these, j conflates utf-8 with 'ucs-1' (a made-up
encoding) and utf-16 with ucs-2 (a genuine, historically significant
encoding). Of these, only utf-8 sees widespread use as an interchange
format. UTF-16 is used by some corners of win32 and the jvm, but that is
pretty much it (and I believe win32 has utf8 interfaces now). UTF-8 has
'won', and I do not think it is worth giving significant attention to
other encodings.
Looking somewhat further afield, there are _thousands_ of historically
significant encodings and codepages. I do not think it is sensible to
provide first-class support for them all. Nor do I think it is desirable.
It might be interesting to provide _decoders_ and _encoders_ for some
(treating the foreign encoding as a sequence of opaque octets, not
characters), but always in terms of the common canonicalization of
unicode.
...but I do not see what aspect of my proposal you object to, and it seems
to avoid this issue.
-E
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
