On Sun, 20 Mar 2022, Raul Miller wrote:
Getting there, from my perspective, should be thought of as critical for
any valid proposal.
I do not see the point in planning a route before I know my destination.
Now... your proposal -- which would have the unicode latin-1 code plane
be the default interpretation for J's literal datatype when (for
example) promoting from literal to unicode4 -- does sound attractive.
In context of your example, that is the current behaviour.
Thinking in terms of implementation, a key concept embedded in your
proposal is that we remove the ability to talk directly with OS
interfaces which expect utf-8.
1. I am not sure why you say you are ignoring fread/fwrite, when
fread/fwrite seem like essential tools for talking with OS interfaces.
2. That ability would not be removed. Functionality for interacting with
OS interfaces would, generally, interpret data received as being
utf8-encoded, and decode it.
Making J be a unicode language instead of an ascii language is something
I remember proposing, years ago.
Curious, what did this proposal entail? I can imagine many things that
might be called 'making j be a unicode language', like:
1. Not forbidding non-ascii characters in names;
2. Using non-ascii characters for primitives;
3. Interpreting unicode whitespace, numerals, quotation marks, et al as such
2 is fraught. 3 means changes to unicode are changes to j. 1 seems
fairly straightforward.
-E
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
