A Quick Look at K

Dick Bowman

Contents

K represents current (or at least recent) thinking by Arthur Whitney, following on from A as a distillation of some of the ideas of APL; a download evaluation copy may be obtained from Kx Systems and it is on this that this brief review is based.

Download and Installation

Three files are provided:

The evaluation version is referred to throughout the documentation as K-Lite and is (I quote) 

"[...] a subset of the K product.  K-Lite is a time-limited, reduced version of K which enables interested developers to learn the language and develop small applications. K-Lite consists of the K language and interpreter, GUI software, and ASCII file read/write capability. It does not include connections, file mapping, interprocess communications or runtime capabilities. K-Lite is for educational purposes, and is not intended for commercial use. Accordingly, Kx Systems does not provide training, technical support or upgrades. K-Lite is not meant as an alternative to K, but an introduction to it.".

Installation is a simple matter of unzipping the downloaded files and running the setup routine;  you will find files called k.exe and krt.exe (both about 5kB), k20.dll (165 kB) and k.lic (8 bytes) added to your WINNT folder (this review was run on a dual Pentium II-233 with 128mB RAM running Windows NT 4.0).

Add a desktop shortcut to k.exe and you are ready to roll.

Return to Contents

First Familiarisation

Start K and you see (with an initial "is it APL" question-and-answer from me)

Sure enough looks like APL; do some experiments and you see enough familiar phrases doing the right sorts of things.

The other thing you'll have noticed by now is that K (certainly in its K-Lite version) extrapolates further along the simple-and-clean lines which distinguish J from (say) Dyalog APL.  Actually there is a degree of customisability, but it's no "count the floating toolbars" product.

Return to Contents

Time to Read the Manuals

The 85 page User Manual introduces the concepts of K, dividing itself between discussion of specific functionality (variables, functions, operators) and a sample application.

What it makes clear from the outset is the defining nature of K data, which may be either atoms or lists (scalars and vectors, to the APL-knowledgeable); lists may themselves be comprised of lists.  So we have the potential for nested data, but not for multidimensionality (at least, not in an explicit form).  In the past some people (I think Gerard Langlet in particular) have claimed to do all of their APL work using nothing higher than rank-1 data; but I feel that here we begin to see where the trade-offs come in choosing whether or not K is a good tool for a particular application.

Some other issues which raise themselves from working through the User Manual:

The User Manual is clearly written, and takes time to introduce its subject matter.

The 242 page Reference Manual performs the expected role, acting as the definitive guide to K.  Once again, a thorough read gives insight into what K is all about:

Return to Contents

Write Some Simple Applications

These examples show the script at left and the result of running it on the right

Hello World

Everybody loves it...

hello:"Hello World"
`show $ `hello

Variable Dependency

Setting up a pair of editable values, and a dependent; type in the editable cells and the dependent value changes automatically (no code is actually "running" while the display is current, compare - for example - the need for a callback in Dyalog APL).

\d .vars
x:3
y:4
sum..d:"x+y"
sum..e:0
`show $ `.vars

Notice also that any attempt to change a value to a non-integer in the display produces an error, although it is valid to set a non-integer value in the K session.

Contents of a Text File

x:0:"j:/k/afile.txt"
`show $ `x

Simple applications require very small coding effort.  The only problem I have here is that I couldn't find an easy way to copy code from the K session into a script (perhaps it's not possible, perhaps I need to look a little harder).

Return to Contents

Performance

Adopting the traditional APL/J benchmarks is instructive, here's a script for the first few:

CV:" ABCDEFGHIJ"@1000 _draw 11
IV:_500*1000 _draw 0
IM:50 -1#IV
FV:IV+.01*1!IV
FM:50 -1#FV
BV:1000 _draw 2


"Int Add : "
\t do[100;IM+IM+IM+IM+IM]
"FP Add : "
\t do[100;FM+FM+FM+FM+FM]
"Int Mult : "
\t do[100;IM*IM*IM*IM*IM]
"FP Mult : "
\t do[100;FM*FM*FM*FM*FM]
"Index : "
\t do[100;&BV]
"Char compress :"
\t do[100;CV@&BV]

From which we observe:

For all of that, on these data samples and these expressions, K does not appear to have any performance shortcomings.

Return to Contents

A More Ambitious Application

The goal of the application was simple statistical analysis of the contents of log files created by another application, in more detail:

I couldn't find a way to achieve the first step (choosing from a list of files) because although there is a command to issue operating system commands the effect of commands is to display in the session log and I couldn't find any way of capturing the information in a K variable.  So, working from a given set of files:

files..o:`"j:/myk/logset1.txt"`"j:/myk/logset2.txt"`"j:/myk/logset3.txt"
files:files..o[0]
files..c: `radio
loginfo..d:"0: files"
loginfo..e:0
types:" FF "
values..d:"(types;15 9 7 54) 0: files"
time..d:"values[0]"
cost..d:"values[1]"
cost..c:`chart
max:{|/x}
min:{&/x}
avg:{(+/x)%#x}
`show $ `files
`show $ `loginfo
`show $ `cost
\d .stats
maxcost..d:".k.max[.cost]"
maxcost..e:0
mincost..d:".k.min[.cost]"
mincost..e:0
maxtime..d:".k.max[.time]"
maxtime..e:0
mintime..d:".k.min[.time]"
mintime..e:0
avgcost..d:".k.avg[.cost]"
avgcost..e:0
avgtime..d:".k.avg[.time]"
avgtime..e:0
`show $ `.stats

File selection

Raw data

Simple statistics

And a graph

 

Not entirely in line with the specification, and an end-result which is probably fairly laughable to the knowledgeable, but what's most interesting is the fact that everything is controlled by the setup rather than "execution-time" code.  Load the script and all the forms are filled with data; select a different file and the changes ripple into all the other forms (non-procedural, that's the word).

I feel a lot more satisfied with this than I do about an essentially similar version I wrote in J, even though it does less.  Perhaps that's just the joy of triumphing over novelty..

Return to Contents

Conclusions

K represents a refinement of APL concepts, one which could be considered in a similar light to J.  It doesn't appear to be carrying a lot of the "attitude" which has made life so difficult for J, and which J has also used to make life difficult for itself.

The major trade-off for K is having a data model comprised of lists of lists; possibly it would have been illuminative for someone versed in LISP to do a comparison between LISP and K (they may be quite different - I don't know).  This restriction may make a transition from APL (or J) to K more difficult for an experienced APL (or J) user and may in fact delineate a class of application for which J is inappropriate (multi-dimensional data applications).

K's GUI derives its power from the tight coupling between itself and K's variables; it does not seek to offer the "emulate MS Office" capabilities in (say) Dyalog APL and this may limit the acceptability of K in a world which measures user interfaces by their conformity rather than their appropriateness.

Learning to program with K will probably come most easily to people with some sort of array programming background, but it is quite different from either APL or J and may present problem to people attempting to use K interchangeably with their APL or J work.

I'm not wholly convinced that scripts are inherently the best way to hold programming work (the difficulty that J poses - for example, "find all my scripts which contain a definition of a verb called..." - arises again here with K.  Agreed that saved workspaces are also not necessarily universally correct either.  Maybe we need a language with an inherent "function file" capability.

The financial step between K-Lite and the full product is (I believe) a substantial one, and this may well inhibit lone explorers from wanting to invest too much of their own time in K.

Some aspects of K, like the "programmer/session" only aspect of commands remind me of early days of APL, and make me think that there may be a lot of non-glamorous enhancement needed before K can seriously take on a general-purpose role as a programming tool.

But, above all, I liked the feel of K - and I'd like to find a way of carrying on with it.

Return to Contents

Return to the J\APL Contents page

Copyright Dick Bowman, 1999-2013; latest update 8 March 2013 (repaired links)