And, I should add, that I guess that ": on boxed data must also convert between literal types.
But even there, it's not necessarily about literal treatment of the contents. Consider, for example, how boxed linefeeds get converted to spaces. Thanks again, -- Raul On Sat, Mar 19, 2022 at 7:50 PM Raul Miller <[email protected]> wrote: > > On Sat, Mar 19, 2022 at 5:47 PM Elijah Stone <[email protected]> wrote: > > But there are limits. I do not need to carefully track which words are > > integers and which are floats. > > This is sometimes necessary. I've worked with examples where > distinguishing between numeric types has been a critical issue. I have > even encountered examples where the distinction between integer and > floating point was key. > > Here's a trivial example: > > 12345678987654321 > 12345678987654321 > <.12345678987654321. > 12345678987654320 > > Manipulations of fixed width numbers have remarkable efficiency, but > they require tradeoffs, and the programmer would do well to be aware of > those tradeoffs. > > Floating point trades some integer precision for the ability to > represent fractions and very large values. > > > > I also object to any proposal to retract language primitives where we do > > > not have demonstrated working replacements whose merits we are judging. > > > (I could go into more detail on how I think these issues should be > > > approached, if you like.) > > > > Please do. > > https://code.jsoftware.com/wiki/Essays/Deprecation > > > 3. The language is not consistent; ": treats text as if it were > > utf-encoded, but promotion (} , " etc.) treats text as if it were > > ucs-encoded. > > In fact, ": converts non-textual content to ascii (which is a subset > of all unicode encodings). It does nothing to content which is already > textual, though in a sense you are right that the algorithm we use for > wrapping text in boxes tries to be aware of the unicode display width > of the contained text. > > The fill mechanism only presumes that the data is in a form which can be > filled with the default fill for that type. If that's not what you want, > you should avoid operations which add fill. For example, you may want > to use an expression like: > > ; verb each sequence > > > 4. I think that issues of interoperability _are_ important, and still > > worthy of discussion. For instance, more consistent display (and this > > is arguably not a foreign issue, but ":'s fault) would make clear what > > was happening with x, y, and z. > > Generally speaking, if you want an unambiguous representation of your > data, you should use something like {{ 5!:5<'y' }} rather than ": > > > > Taking a step back to your opening example in this thread: > > > > > > Your z was not a valid utf-32 sequence. It would represent a valid utf-8 > > > sequence, *if* the programmer treated it as such. When treated as a > > > utf-32 sequence, the result would be invalid. > > > > That's part of the problem. z is a perfectly good, valid utf-32 sequence. > > Hmm... I suppose you are correct. Which means the problem here is that > it is not being displayed correctly. > > Thanks, > > -- > Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
