Comment by geocar | Hacker News Reader

Comment by geocar | Hacker News Reader

Parent Full thread

Without trying to speak to why "katlang" does what it does, there are other languages that do this and I can speak to how useful it is when you already prefer functions of low arity: It repeatedly demonstrates a substantial improvement in bug/defect reduction and code.

APL does this; a function like {ω×α+ω} and assigns omega to the right-argument, and alpha to the left-argument. They also have ωω for the right-side function and αα for the left-hand function for writing higher-order functions. Dyadic expressions tend to modify their right-hand argument, and not the left, so for the times that the arguments are "backwards" this can usually be fixed with the commute operator (⍨) which looks similar to katlang's "grace" operator (~) so I assume at least some influence.

k/q does something more similar: a function like {x*y+x} assigns the first argument to x, the second to y, the third to z. The author seems inspired by this behaviour (even mentioning it in a linked paper). In q, when the function is in the q context, x is the left-argument and y is the right-argument when called dyadically. Sadly, q and k don't have commute.

I will do some research on APL and your mentioned 'commute operator', cannot comment on it now. But regarding languages: k/q the issues with them is that they use x, y and z as keywords for the parameters. x is always the first parameter, y - second, z - third. In KatLang parameter names are not predefined keywords, you can pick almost any parameter names you like.

> But regarding languages: k/q the issues with them is that they use x, y and z as keywords for the parameters. x is always the first parameter, y - second, z - third. In KatLang parameter names are not predefined keywords, you can pick almost any parameter names you like.

They aren't in q either: x can be redefined to whatever you like.

How does KatLang determine which argument is first? Is it merely the first free variable?

Yes, the first unknown identifier becomes the first parameter, next unknown identifier becomes next parameter and so on...

More specifically: the first unknown identifier becomes the first parameter for the closest algorithm defined with {} brackets. Properties (also called named algorithms) are defined as {} context. And KatLang program also is defined as {} context. I call it Second order algorithm - algorithms can contain another algorithms. First order algorithm is something defined between commas or semicolons. But inside brackets () or {} you can define second order algorithm.

You might like looking at how Dyalog handles higher-order functions; John Scholes really put this beautiful presentation together about using them as a depth-first search reusable function https://www.youtube.com/watch?v=DsZdfnlh_d0 and if you haven't seen it, you should!

According to Q documentation, Q supports only 3 implicit parameters x, y, z: https://web.archive.org/web/20190213035913/http://code.kx.co...

They're just variables like any other; {[x;y;z] x+yz} is almost exactly the same as {x+yz}

Can you explain the difference little bit more, Maybe using Javascript pseudocode as comparable example? I want to understand how Q is different from KatLang. The problem with me is that I do not know where I can try Q code, therefore I rely only on the documentation fragments I can find.

Last I checked there was a free download with an email on kx.com

I tested and seems, that x is the first implicit parameter, y - second, z - third. It is as stated in their online documentation. When you try following example:

  {y+x*z}[1;2;3]

It gives result:

5

And in Q you cannot define implicit parameters with names, for example,: a, b, c. But You can define parameters explicitly:

  {[a;b;c]a+b*c}[1;2;3]

I still think that their implicit parameters are keywords. Similarly as keyword 'it' in Kotlin programming language is used to refer to the single parameter of the lambda expression.

In KatLang there are no predefined implicit parameter names. The user is the one who defines implicit parameters by declaring the implicit parameter names.

No. They are not keywords. The program:

    x:42;
    f:{[a]x+a}

is the same as:

    x=42;
    f=function(a){return x+a}

Thanks for explaining! But how about this example:

  x:42
  {x+1}[5]

It results in

It seems like you can define variables with the name 'x', but when you do not have explicit parameters, then the identifier 'x' is used to refer to the first implicit parameter, y - for second and z - for the third parameter. In context of implicit parameters x, y and z acts like predefined keywords.

q's functions don't capture the environment, so that's the same as:

    a:42
    {[a]a+1}[5]

and as in javascript:

    a=42;
    f=function(a){return a+1}

and when i say they don't capture the environment, i mean this:

    f:{[g] {g+x}}

doesn't do anything except generate errors (° there are benefits to this approach!) because the inner function (that we are returning) sees the "global" g and not the one lexically scoped in the function (a better way to say it: no closures).

Reply on news.ycombinator.com