However, it's hard to replicate unix userland as K primitives - Unix pipes work well because every participant streams along implicitly; however, one of the subtle and often invisible truths of APL and K programming is that everything sort of assumes the length of every vector/list/axis/dictionary is accessible. It's not something that cannot be removed, it's just something that AFAIK has never been removed -- and the implications of removing it are likely to make APL or K less concise. Streaming in APL and K tends to be explicit.
K and APL are ridiculously useful, and once you've actually grokked the idea, it's hard to look at conventional programming languages (Java, C, C#, even Python) and not feel disgusted at the useless extreme verbosity and fragile building blocks. Some people use them as their shell, and have no issue delegating to "standard" unix userland. In fact, an older version of K IIRC had its "create directory" operation implemented as {system "mkdir ",quote x} or something like that. It might not look that way to an outsider, but extreme pragmatism is strong with the K community.
Would the k community appreciate this as useful, pragmatic solution?
I am a BSD /emul/linux, /bin/sh, vi-mode, ESC / user. I need searchable commandline history for q)k) and I really do not like rlwrap as a solution.
sources:
http://kx.com/q/c/c/ http://raw.githubusercontent.com/antirez/linenoise/master/li... http://raw.githubusercontent.com/antirez/linenoise/master/li...
while[1;0N!. 0:0]
you can save the history in a table and do whatever you want.Except my lack of creativity using k at this point.
Thanks for this.
As a k noob, I wonder: is thinking of solutions using iteration and control structures a bad habit, at least until I have command of the rest of the language?
Currently I'm using recordio to save my sessions; crude, but it works well enough:
recordio q 2>log socat readline,history=file exec:qUnix and later linux/BSD's took off largely based on their open source and easy to duplicate and deploy (c compiler everywhere), but APL had it's corporative baggage and remained a niche (very much like kdb+ wouldn't go open/libre, and IBM is still charging a fortune for APL2).
[1] http://www-01.ibm.com/software/awdtools/apl/apl2-v2.html