@user41805 I don't think it necessarily has to be that restrictive, but a lot of challenges are either total crap or just not very interesting, so it'd be nice to have some way to cut down on them

I feel like the k's are in a somewhat unique place (from a golfing perspective) of 1) the primitives being shuffled around between versions and 2) having precedence for overloads with what I would say are pretty narrow usecases (=int in k5/k6, floatList$floatList for matrix multiplication in k4, int^intList in k5 (?), etc etc)

and while I've mentioned ideas for adding more golf-y overloads (0N$string to trim leading/trailing whitespace), I am a bit wary of adding things just because they're useful in a golfing contest

but in that context, 1!float feels more like missing functionality/an oversight than anything else

I think my largest frustration (which is still quite minor) with golfing here is that there's going to be a disconnect between the elegance of the answer, the effort invested in coming up with/documenting it, and how much attention it gets

there's a strong bias on the last one for fresh questions/early answers (which I'm fine with), but that also conflicts with the introduction-to-the-language/explaining-some-neat-aspect-of-it answers that personally I think are the most interesting

@coltim yep, this is true in all languages and it's frustrating when a trivial answer gets a lot more votes than one that actually takes effort

(I also really like answers that contain little kernels that can be applied elsewhere. I know I've gone through old k answers and found some useful bits that could be reapplied elsewhere - even outside of a strict golfing context)

@coltim it'd be cool if you kept track of them and published a list

if it makes you feel any better, arthur absolutely does make some design decisions in his K dialects based on golfing problems

many versions have had a handful of weird overloads which just so happen to come in handy when solving sudoku puzzles or implementing the game of life or what have you

@JohnE really?! wow, any examples?

in oK the "n?c" overload is a very strange special case that is basically only useful if you want to generate random data that resembles stock ticker symbols. The edge cases of "window" also come to mind: github.com/JohnEarnest/ok/blob/gh-pages/docs/Manual.md#window

both of these come from k5, to be clear

and =n being the identity matrix is probably a golf thing

@rak1507 @JohnE at some point in k5 there was !-n as "permutations", likely for similar reasons

when I studied and documented !-n it was count up from -n, which again probably saved characters in some esoteric problem

yeah that's what it does in ngn/k

except in k5 used to have subtly different semantics- it would remove the first instance of each item in y from x instead of all instances. I found a few interesting idioms which took advantage of this behavior, but when I pointed it out to Arthur he said it was a bug and corrected it

@rak1507 because ^^^that is how i found out it had been changed :) (from JohnE's docs)

bugs?! in whitney's code?! I thought that was impossible!

nyi:nyi:nyi:nyi:nyi:nyi:nyi:nyi:nyi:nyi:nyi:nyi:nyi:nyi:nyi:nyi:nyi:nyi:nyi:pipe lol fun ngn/k error messages

ngn/k and oK are basically twin sisters, diverging at the fringes a little where k5/6 had holes

@JohnE to be fair, that looks like a more natural extension of !n

sure

@user14609697 hi, if you want write access here, please drop a line to ".@acgiklmnov"@9 5 3 6 0 9 5 3 6 10 7 10 11 1 4 8 2 5 7 0 3 10 8 (evaluated as k code) and i'll ask the moderators to grant it

k3 had a pretty nasty bug in its implementation of sm[], where certain combinations of needle and haystack could blow the stack and segfault. When I was working at 1010data I wrote a drop-in replacement in C which handled every case correctly and ran within a factor of 2x slower than arthur's

lots of fiddly details to matching the bizarre behavior of escapes in character classes in sm[] patterns. A fun problem overall.

@rak1507 bugs - of course :) but when there's so much less code than similar interpreters, they must be easier to find and fix

I'm still not convinced...

@JohnE are there any available docs on k3? I've seen some k2 stuff on nsl

the main thing about K interpreters is that they have very large amounts of surface area to volume, so to speak. Sort of like the lining of a large intestine. Remarkably challenging to test adequately given the number of features in the language

@coltim none that can be shared. Everyone at 1010 uses the K2 docs and they are extremely similar languages.

I have a binary of k3 for personal use, so if anyone ever has a burning need to know something I can run experiments, but I cannot distribute it or the requisite license file

@coltim docs - yes but they are a secret too :(

figures =P. going off of _sm in the k2 docs, is sm similar to k4's simplified regexes?

yes; also identical to sm/ssr as described in the k2 manual

the only real differences between k2 and k3 are that k3 has no gui facilities, it has a few more builtins, and the branch maintained at 1010 ("e") has a variety of additional builtins and capabilities like forking, access to shared memory, and some quality-of-life stuff like filter/filter-out on f#x/f_x

I don't think any of it would be an earthshaking revelation to someone familiar with k2

@JohnE are you still gonna keep using k3 ("e") when k9 is out? (you don't have to reply if you're not supposed to)

well I don't work at 1010 anymore so I don't really use k3 for anything

I believe they are experimenting with k9 but frankly it has always seemed far too volatile to write anything serious with

it would be a ton of work, and of questionable payoff, to rewrite the 1010 codebase in k9, but perhaps it could be done a few services at a time

volatile - yeah, maybe it needs time

legacy code is a great evil, as everyone coming from apl is well aware..

@chrispsn it's not easy to track down specific answers, although going forward I'll take notes. at a high level, it generally takes the form of borrowing some neat tricks (e.g. 2&$x instead of (#x)#2), or just wholesale lifting some higher order logic (e.g. getting the power set of some input)

as for what has helped me outside of golfing I think it's mostly been working with boolean lists. things like &\ to 0-out everything after the first 0, or using < or > the way that you would normally use and or or in e.g. python

also just getting more familiar with using the monadic-function forms of / and \

maybe x_/|y too, as a substitute for k2's _di (delete indices)