I should mention, here, that I am ignoring the "fread/fwrite" part of your proposal, for now, because your motivating examples did not involve the use of fread nor fwrite.
-- Raul On Sun, Mar 20, 2022 at 11:36 AM Raul Miller <[email protected]> wrote: > > 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
