On Sun, 20 Mar 2022, Raul Miller 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.
It's my understanding that ucs-2 is a subset of utf-16.
More or less. But j plays fast and loose with utf, and in particular
could have ignored surrogates.
Every primitive is in some sense "inconsistent" with other primitives,
because every primitive accomplishes something different.
The ": primitive is about formatting text for display. That is going to
have to be different from an operation like addition.
Arguably, - is inconsistent, as x-y takes _x_ as primary data, and moves y
units with respect to it. More famously, % and | are not consistent with
each other, as % takes its divisor on the right, and | takes its divisor
on the left. I could argue that % and - should be flipped (and others
_have_ argued thus). But I don't, because there are also merits to the
extant scheme. To wit, % and - follow existing mathematical and
programming notation (as does |; a|b can be used to denote that b is
divisible by a), and they behave sensibly and usefully as monads.
But--two issues.
The first is that ": must still stand on its own merits; it is not enough
to say that inconsistency is inevitable. Why is this the best way to
format text? And is consistency between primitives _undesriable_? Under
my proposed semantics, ": would behave consistently with other primitives.
Second, and more important, is that the inconsistency is different in
kind. % and | agree that a 5 is a 5. But whereas ": thinks that (8
u:243) is a LATIN SMALL LETTER O WITH ACUTE, other primitives think that
it is a LATIN CAPITAL LETTER A WITH TILDE followed by a SUPERSCRIPT THREE.
Ah, that was my browser / email client messing up.
Just to avoid any ambiguity: the correct display of z is as a lowercase a,
uppercase A overstruck with a tilde, superscript 3, lowercase b.
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.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
