Arc Forumnew | comments | leaders | submitlogin
4 points by sa 6150 days ago | link | parent

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.