Hacker News Reader

Comment by mlochbaum | Hacker News Reader

Sounds like you're generalizing, based on... early APLs? NumPy? You could translate any BASIC code to, say, Dyalog APL easily without significant loss in fidelity. Different languages take different approaches but most modern ones (the ones that aren't just made to be calculators like Ivy) support either a generic functional or imperative style just fine.

K is inspired by Lisp, although you can't adapt that style directly because of the limited scoping rules: variables are either local or global, so a function can't see variables from containing functions. This means no closures, which K implementers consider a feature (I don't).

View on HN

> 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

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.

> 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.

No closures is one of the biggest pain points of k/q, it's incredibly limiting and frustrating. Besides that though, it's a wonderful language which allows you to solve problems very quickly with pretty good performance, assuming the problem is naturally vectorizable.

Reply on news.ycombinator.com