Comment by Bostonian

4 years ago

Do Octave and R qualify as array languages? You could say that Python is not because Numpy is not part of the language.

8 comments

Bostonian

Reply
mlochbaum  4 years ago

It's hard to say how exactly to draw the line, but "array language" to an APLer usually means a language whose primary influence is APL. So these scientific languages that throw out most of the syntax are nearby but don't quite belong. From a practical standpoint the APL Wiki is centered on APL and exists to document the kind of niche material Wikipedia wouldn't cover, which is why there's nothing about these more mainstream languages currently.

stingraycharles  4 years ago

I’d argue that array languages are far, far more limited than Python, to the point that the only thing you can reasonably do with them is processing array data (but they’re really good at it!)

  • mlochbaum  4 years ago

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

    • eiz  4 years ago

      > 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

      2 replies →

    • smabie  4 years ago

      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.