K is actually a very good language for Arc to steal ideas from. It's extremely concise (although it doesn't have to be line noise as above) and it does everything with lists.
yes, it doesn't have to be line-noise - see eliza.q for an example. q is k without ambivalence: symbols denote only binary functions, unaries have keywords. e.g. in k x+y is addition, +x is transpose; in q, + is addition, flip is transpose. the q programmer can go further down this road, e.g. define x#y as 'take', then use x take y. as i mentioned in a follow-up on comp.lang.functional, part of how k achives concision is to keep the primitive-set small and orthogonal on a small set of datatypes. the programmer seeks representations which are tuned to the primitives. i think of this as coding to the grain of the language.
a small but important correction: k doesn't do everything with lists (althought it does do a lot with them.) k has atoms and lists. it also has dictionaries (maps of names to values), tables, which are transposed dictionaries of lists, and keytables, which are maps from utables to tables, where a utable is a table of unique records. as pg knows, it has first-class functions, but not closures.
people outside the k world may have the impression that k is just APL with an ascii character set. at this point in its development, i think it is more useful to think of k as a functional query language. in APL, the primitives understand atoms and lists (scalars and arrays). in k, they also understand maps, since a table is a transposed map of lists, a table is also a list of atomic maps.
i hope these remarks are useful to all of you arcturians.
