Underneath q is k

https://learninghub.kx.com/forums/topic/underneath-q-is-k

The q operators and functions are a combination of optimized c functions and wrappers on top of the k language.

k preceded q by about a decade. These days you are supposed to write q code so k is not documented anymore, unfortunately parse trees and debugging require some knowledge of k.

So how do we translate between the 2 languages?

The .q namespace contains all the bits of q which are are wrappers of k and hence gives us a good starting point.

If we type lj we can see its definition, .q.lj is the fully qualified name.

q)lj 
k){$[$[99h=@y;(98h=@!y)&98h=@. y;()~y];.Q.ft[,:[;y];x];'"type"]}

In order to understand this we need to know what @ and ! mean in k.

So lets take .q namespace, and filter out all the functions, this gives us a good starting point for translating q into k.(I have manually rearranged the results to group similar things together)

 

c 2000 200 
q)where[1_not type'[.q]in -10 100 106 110h]#.q neg | -: not | ~: hdel | ~: null | ^: string | $: mmu | $ reciprocal| %: ltime | %: floor | _:

 

There are 5 categories. We already excluded lambdas, aliases of internals like -15!, projections like ceiling(neg floor neg@), named adverb’ed operators like sums, and the k operators.

Both get and value map to the same k operator which is why they are used interchangeably when people write code. Many of the operators are overloaded like ! which does both inv and key depending on the input.

In k we use a trailing : to indicate that the operator is being used in its monadic form. The : is only required when the statement is ambiguous, the alternative to using : is to use @ or () eg:

 

I have written a utility that converts k code to q (not necessarily the prettiest version) by parsing it and then rebuilding the code from the parse tree in q format. It can be found here:

https://github.com/gyorokpeter/qutils/blob/master/q/k2q.q

https://kparc.com/

https://kparc.com/k.txt

q is built on k4, but shakti (k9) has many similar aspects to the k4 language and is better documented here: https://estradajke.github.io/k9-simples/k9/index.html

On your last point, worth mentioning that using brackets to wrap k code is not encouraged: https://code.kx.com/q/basics/exposed-infrastructure/#unary-forms. (I think I heard somewhere that this usage is actually an issue with the parser - but don’t quote me on that.)