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
