On Sun, Mar 20, 2022 at 2:38 AM Elijah Stone <[email protected]> wrote: > > Deprecation based on something which has not been implemented is bad > > news. > > What are you getting at? That I did not include a deprecation plan in my > proposal? I would like to first establish what the ideal semantics should > _be_. Getting there is secondary.
Getting there, from my perspective, should be thought of as critical for any valid proposal. > > I think a point has been lost here on why getting rid of u: would not > > change anything about the initial example in this thread: > > I think I addressed this; maybe I was not clear enough. Removing u: alone > is not sufficient to solve the problem; but it is necessary, and my > proposal in its entirety remedies the problem. From my perspective, the problem is inherent in the *unicode* specification. It's not a problem in the J *language*. (J is based on ascii, not unicode. J has added some minimal support for unicode, which is also based on ascii.) So, from a language perspective, we could obscure the issues. But the underlying "discontinuities" would remain. 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. And, that is similar to historical J (where we also treated those characters as representing the latin-1 code plane, instead of utf-8), and we moved away from that because of the ubiquity of utf-8 in OS interfaces. (Making J be a unicode language instead of an ascii language is something I remember proposing, years ago. But the work involved is overwhelmingly open-ended. (If you want a unicode language, I think raku is a great start. And, since the raku design proposals explicitly include the capabilities needed to have J as a subset of the language, I imagine that eventually you could load J packages directly into raku, perhaps even with version support so that deprecated J graphics code could function there. Eventually. (Probably with some performance penalties or possibly even performance improvements, though that issue is less clear.))) Anyways, ... 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. But that seems to conflict, directly, with the principles you proposed as the motivation for your proposal. Why would you do that? Thanks, -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
