Why was $ changed so that strings are no longer a fixed point of thatverb? E.g.,(“aa” ~ $“aa”) is true in K3 but false in K4. The K4 behaviour isaberrant, I would say.
X-Mailer: Apple Mail (2.930.3)yes, it is annoying. but the reason for this is orthogonality of language.you can use this instead of “string”:str:{$[10h~type x;x;$x]}On 18 May 2009, at 03:29, annakh7 wrote:>> Why was $ changed so that strings are no longer a fixed point of that> verb? E.g.,> (“aa” ~ $“aa”) is true in K3 but false in K4. The K4 behaviour is> aberrant, I would say.> >
Exactly how does it make the language more orthogonal in this case?
X-Mailer: Apple Mail (2.930.3)is exactly likestring 1 2 3a string is a vector of chars.On 18 May 2009, at 13:33, annakh7 wrote:>> Exactly how does it make the language more orthogonal in this case?>> >
I think that’s taking orthogonality as a fetish. “abc” -> enlist each"abc" looks likea pretty useless transformation to me, if only because you can use’enlist each’like I just did if you really need it, and usefulness should trumporthogonality.One sometimes gets the feeling that AW sat down and decided to dothingsdifferently for the sake of doing something different, not because theold waywas particularly wrong or the new one markedly better…
X-Mailer: Apple Mail (2.930.3)i don’t like it either. there were a lot situations where i had to work around this.On 19 May 2009, at 00:40, annakh7 wrote:>> I think that’s taking orthogonality as a fetish. “abc” -> enlist each> “abc” looks like> a pretty useless transformation to me, if only because you can use> ‘enlist each’> like I just did if you really need it, and usefulness should trump> orthogonality.>> One sometimes gets the feeling that AW sat down and decided to do> things> differently for the sake of doing something different, not because the> old way> was particularly wrong or the new one markedly better…> >
string x is the inverse of type$x
string is atomic and always produces a list of characters
for each atom.
-3!x is a partial inverse of value x
X-Mailer: Apple Mail (2.935.3)
i have to agree with Felix and annakh7
in this particular case and in some others as well
.e.g each-prior, v[i;j]-:, namespaces (this seriously bugs one of my
colleagues)
k4 has the more regular and simpler (to implement…), but less useful
behavior
which would be kind of OK if because of simplicity it would be faster
than k3, which it is not in most cases
.e.g
l:!1000000
\t do[10;$l]
k3: 1886ms, k4:2152ms
but i guess AW still prefers simplicity in the implementation
and to be fair k4 has to handle a lot more types
and k4 has plenty of other virtues
note that to recreate the k3 behavior (which handles arbitrarily
nested lists)
one can write something like this
q)str:{$[0=t:type x;.z.s each x;10=abs t;x;string x]}
q)str (“abc”;`def;(42;5 7 6))
“abc”
“def”
(“42”;(,“5”;,“7”;,“6”))
but it can’t handle as deeply nested structures as k3
and it is obviously slower
although probably there is no need? ;)
k3:
l:{(x;y)}/!100000
\t do[10;$l]
946
k4:
l:{(x;y)}/!100000
\t do[10;$l]
Segmentation fault
and it was not even str…
ok, let’s try something smaller
l:(;)/!10000
\t do[100;$l]
1410
\t do[10;str l]
‘stack
@
{$[not t:type x;.z.s each x;10=abs t;x;string x]}’
l:(;)/!1000
\t do[100;str l]
561
let’s compare it to k3
\t do[1000;$l]
344
the k3 primitive in this pathological case is more than 20 times faster
but to be fair, k4 never pretended to care that much about strings, it
is not perl…
Attila