K Fragments

Sorry. This page wasn't really written as an introduction; more a collection of ideas.

To break that example down for you, the outer {} indicate that this is an anonymous function. It is implicitly a function over a single argument named "x"; our list of dictionaries. Expressions read right to left, so the first semantic unit is:

    k:?,/!:'x

The variable "k" gets the distincts (?) of the concatenate-reduction (,/) of the keys (!:) of each (') dictionary:

      !:'x
    (,`a
     ,`b
     `a `b)

      ,/!:'x
    `a `b `a `b

      ?,/!:'x
    `a `b

The other embedded lambda "{x@&~_n~/:x}" is read as "x indexed (@) by where (&) not (~) null (_n) matches (~) each-right (x)"; it filters nulls from a list.

      _n~/:(22;;33;55)
    0 1 0 0

      ~_n~/:(22;;33;55)
    1 0 1 1

      &~_n~/:(22;;33;55)
    0 2 3

      {x@&~_n~/:x}(22;;33;55)
    22 33 55

Then the overall construction "{x@&~_n~/:x}x@'/:k" can be understood as "reach into each dictionary with all the keys and filter them to non-null values". Now you have a list of lists of values in the order that the keys appeared.

Finally, ".+(k; ... )" joins our keyset with the values we found for each key. Make dictionary (.) from the transpose (+) of the pair of vectors (k;v).

Does that help?

At a glance, I would think someone was programming using just regular expressions. Or maybe speech-to-text translation of line noise.

It looks way too long in the number of different tokens.

  This is the TXR Lisp interactive listener of TXR 233.
  Quit with :quit or Ctrl-D on empty line. Ctrl-X ? for cheatsheet.
  1> (defun merge-hashes (hlist)
       (let ((hout (hash)))
        (each ((h hlist))
          (dohash (k v h) (push v [hout k])))
       hout))
  merge-hashes
  2> (merge-hashes '(#H(() (a 1) (b 2) (c 3)) #H(() (b 5) (c 7) (d 8))))
  #H(() (c (7 3)) (b (5 2)) (a (1)) (d (8)))

Now here is that function fully code golfed with unnecessary spaces removed and all symbols one character long:

  (defun m(x)(let((o(hash)))(each((h x))(dohash(k v h)(push v[o k])))o))

That's down to 70 characters: only about double the K3 size.

If defun and the other built-ins were one character long, it would be down to 50 chars:

  (d m(x)(l((o(H)))(e((h x))(D(k v h)(p v[o k])))o))

Now we have a fair comparison where we have leveled the field, eliminating the difference due to whitespace elimination and token condensation.

Though still significantly by raw character count (35 versus 50), there is less clutter in it. Also, it defines the name m whereas the {.+...} syntax needs a few more characters to define a function, I think.

But wait; that's far from the shortest code necessary. What I wrote is a decently efficient way of doing it which iterates the input hashes imperatively and builds up the output. It can be done in other ways, like this:

  1> (defun merge-hashes (hlist)
       [group-reduce (hash) car (op cons (cdr @2) @1) [mappend hash-alist hlist]])
  merge-hashes
  2> (merge-hashes '(#H(() (a 1) (b 2) (c 3)) #H(() (b 5) (c 7) (d 8))))
  #H(() (d (8)) (c (7 3)) (b (5 2)) (a (1)))

We can obtain a flat "assoc list" of all the key value pairs from all the dictionaries by mappend-ing them through hash-alist. hash-alist retrieves an assoc list from a single dictionary, and we map over that, appending these together.

Then we can group-reduce the assoc list; group-reduce populates a hash by classifying elements from an input sequence into keys, which denote individual reduce accumulators. So all the a elements are subject to their own reduce job, so are the b elements and so forth. The reduce function is (op cons (cdr @2) @1); an anonymous function that takes the cdr (value element) of each pair (that pair coming as argument 2), and conses it onto the accumulator (coming in as argument 1), returning the new accumulator. Since nil is the empty list, and fetching a nonexistent hash key yields nil, the accumulation can boostrap implicitly from an empty hash.

Now if we were to remove all unnecessary whitespace and give a one-character name to everything, we now get:

  (d m(h)[R(H)c(o n(r @2)@1)[M L h]])

That shows there is a potential to get this down to 35 characters, with suitable function/operator and variable names.

Moreover, these 35 characters are yet easier to parse because all the parentheses/brackets are there: they comprise 14 out of the 35 characters! And we still have 5 spaces. So 19 characters out of the 35 are punctuation having to do with shaping the syntax; 16 are semantic.

If you remember that R is group-reduce, you know that its arguments are (H) c (o ...) and [M ...]. There is no guesswork about what goes with what.

The above K expression is actually verbose because it doesn't use very many characters for shaping the syntax tree. Most of the characters you see do something.

Languages like K leverage their terseness not just from compression of the input notation, but from the semantics of the operations. But they do not have a monopoly in semantics. Good semantics that enables terse programming can be found in languages that don't use terse notations at the token level.

The K3 example we have here is not leveraging good semantics; if that's the best that can be done, it suggests that k doesn't have a well-rounded library of operations for concisely manipulating dictionaries. (Could it be that the insistence on one-character names creates a pressure against that?)

It's better to have thousands of functions with descriptive names, and then be able to choose the best ones for expressing a given problem tersely, than to reach for one-letter naming as the primary means for achieving terseness, and then try to pull a one-size-fits-all library within that naming convention.

Varies. I think among these examples "is interleave?" and "limit run length" require some thinking, or a bit of playing in the REPL. Most of them are pretty easy to follow, though.

K is a vector language. There is indeed some overlap in ideas with Mathematica and Lisp, but it draws most heavily from APL. There are a handful of decent open-source or at least freely available interpreters online:

https://ngn.bitbucket.io/k.html

I would recommend getting started with q, instead of k. q is a lot easier to get started with and after you learn the basics (takes maybe a day or two), learning k is much easier. A good resource is: https://code.kx.com/q4m3/

k/q aren't actually very difficult to learn, you can memorize the entire language in a period of a day, maybe. The hard part is actually writing good code with it. I could spend the rest of my life programming in k and never be 1/10th as good as Arthur Whitney (the creator).

I think people are getting excited by Shakti (or maybe it's coordinated?). I'm hoping array programming is going to break into the mainstream, it's remarkable that even many experienced programmers know nothing about array languages. And when exposed, most just dismiss them out of hand as 'unreadable' or 'line-noise.'

They are clustered probably because HN readers see one story, and then find and submit similar content that they encounter.

The same thing happens with gwern or rachelbythebay blog posts. If you see one, you will see more in the next week or so. But then it dies off

What is Shakti?