[eiz]

> This means no closures, which K implementers consider a feature (I don't).

having not touched K in about 15 years, when did this change? in k3:

    K 3.2 2004-09-23 Copyright (C) 1993-2004 Kx Systems
    LIN32 16CPU 15985MB ubuntu 0 EVAL  
    
      f:{a:x+1;{a+x}}
      g:f 1
      g
    {a+x}
      g 2
    4
      a
    value error
    a
    ^
    parse error

[mlochbaum]

This comes as a surprise to me! I thought none of Whitney's Ks had closures—although I did neglect to mention that kuc and oK add them. Digging around and asking on the K Matrix/Discord I found some posts that suggest that the K3 form is very limited. My read of these is that functions can refer to variables in the immediately surrounding scope (only one level up), and their values will be copied in when the function is reached in the source code. So it would be equivalent to adding extra arguments to g and passing the variable values in that way. And it wouldn't allow the programmer to create object-like things and couldn't create reference loops requiring garbage collection.

See https://news.ycombinator.com/item?id=22572778, as well as https://chat.stackexchange.com/transcript/message/53999576#5... with more discussion on following days.

[moonchild]

> their values will be copied in when the function is reached in the source code. So it would be equivalent to adding extra arguments to g and passing the variable values in that way. And it wouldn't allow the programmer to create object-like things and couldn't create reference loops requiring garbage collection.

That is definitely desirable! K (and kin) are fully referentially transparent and have value semantics. It would be bizarre and inconsistent to break referential transparency for closures.