nice:

2020.03.26 (c) shakti
 2 3_10
0 1 4 5 6 7 8 9

not nice:

the help is gone!

yeah - have queried

i still have the help on mac

@rcabaco is there any change with respect to the previous version?

i didn't look at the previous version

arthur is ecstatic over the new semantics for # and _.

my current bugaboo is the use of symbols for auxilliary (system) functions, like k@ and k?. i've suggested the following scheme: where f1, f2, etc. are lambdas with valence 1, 2, etc. then f:(f1;f2;..;f8) gives you polyadic-ambivalent f, and f:(f1;g1) gives you f@x = f1 x and f?x = g1 x. then k@ and k? become k@ and k?.

moreover, any function defined in z.k is, as now, available everywhere on the tree. this new proposal also frees up `a@ to mean "apply/index the global a", which is consistent with k3 and (if memory serves) k4 (useful from within a lambda to reference global a). ultimately, i would like to see <. list> take on the meaning it has in k3: . v, .(v;i), .(v;i;f), .(v;i;f.d).

this chat software appears to eat backtick.

@StevanApter it interprets two as a code-block. iirc, you can escape it by preceding a \

a bug in k9

?

2020.03.26 (c) shakti
 @[;2]1 3 6
2

@Traws probably. it looks wrong with swapped args too: 2@1 3 6 -> 2

@StevanApter keywords, f:(f1;f2), etc - doesn't it bother you that that makes the language not statically parsable? it feels like a big step back to apl

@ktye so, if i want to write, let's say, a syntax highlighter for my fav editor, i would have to write a k parser first, in order to pick up the stuff from z.k

yes that's right.

that's a big difference from the good old statically parsable k

what makes the difference? is it variadic user defined functions?

@coltim a b c - is that a[b[c]] or b[a;c]?

you'd have to look in z.k to tell

hmm, I'm probably not grasping something, but how do the builtin variadic functions (e.g. +) handle that ambiguity? Is it because they're defined to be variadic, whereas a UDF is unknown without parsing it?

@coltim in old k: the parser knows that + is a verb, so to disambiguate between monadic (+:) and dyadic (+) it looks on its left too see if there's a noun there

but this couldn't be done with identifiers (a, b, etc), as they were always nouns

except for a small, not configurable, set of reserved words like in, within, etc - the parser just knew about them

hmm, so if functions (or at least when they are invoked) needed to be specified like 'f (vs. f), would that change anything?

@coltim ' as each? or are you proposing some kind of new syntax?

apologies, yeh more of the latter (it could be anything, e.g. capitalization of the name, just some mechanism to differentiate defined functions from other data variables)

@coltim yeah, something like that could work

@ktye sidenote: terminology is such a mess.. you seem to be using verb and function interchangably

(i am still very much stuck in apl way of thinking)

@cannadayr (continuation from the orchard) the differences between k versions can be confusing. i don't know anything about k2, but i guess it must be somewhat different from k5-6. a brief description of how k versions evolved is available here (via /r/apljk)

@cannadayr ok, so let's take this apart. you know that $[ ; ; ] is cond, right?

yes.

^y means "is null?" in k5-6, so it evaluates to 0 (false)

yes

so, x#y will be evaluated, which is reshape. just like apl's 10⍴10, it returns 10 10 .. 10

@cannadayr actually, are you saying it's wrong or something else?

@cannadayr "null" in k means something specific

every type has it's null value: 0N for int (which is the smallest representable int: 0x800..0 in c), 0n for float (NaN), " " for char

all function types use :: as their null value

and i think i should explain projections (aka curried functions, aka partially applied functions)

you seem to assume f[x] is the same as f[x;]. they are not. the latter is a projection of f over the first argument, something like x∘f in apl

in k you can have up to 8 arguments and you can make a projection with an arbitrary subset of them, eg f[0;1;;;4;;6;7]

ahh interesting. ill mess around w/ this more later. got too distracted from employment. thx for help.

k is def a different animal

in lambdas, x,y,z are implicit arguments, like apl's ⍺,⍵, so {[x;y] somethingwithxy} <=> {somethingwithxy}

@cannadayr yep. apl&j are closer to each other. k is like half-way in the direction of lisp from them.

@ktye :D

implementing a faster apl in k would be the ultimate triumph :)

ngn - you are exactly right - a b c is syntactically indeterminate. i'm not convinced that ambivalent lambdas are worth the cost.

but i'm absolutely certain that f=(f1;g1) is an improvement over the current use of symbols for built-ins, which i've deplored since they turned up (i limit my rants on the subject to one per week)

still, (f1;f2) is an improvement on APL, since one can simply attach z.k to the parser. more complicated, but it's not necessary to actually instantiate z.k.

@ktye "i'm not convinced that ambivalent lambdas are worth the cost." -sa

@ktye "move {E} from n to t" - do you mean "to v"?

@ngn i don't think so. i have it in the "t" function called pt: github.com/ktye/i/blob/master/_/w/k.go#L1371 in my prototype.

maybe you are right.

@ktye and what would that change? a{..}b is rare. the interesting case is f:{..};a f b

a f b would not work. only the literal. it should only be useful for small lambdas.

Since this came up again, and we have quite a few more people here now, I'll mention my idea from chat.stackexchange.com/transcript/message/53350117#53350117 again: use <space><dot>name<dot><space> for statically parsed arbitrarily named dyadic infix; x .matmult. y ; (and similarly "f .adverb x" and for symmetry "monadic. x")