Comment by riazrizvi
6 hours ago
No, not in a programming language sense, because arrays are a notation for address offsetting, whereas functions change the execution context of the machine, which is critical to processing performance (think Horner's method).
Not even in a functional sense because, even though functions are input-output maps we define, the inputs are dimensionally rich, it's nowhere close to equivalent to jerry rig a contiguous input space for that purpose.
> the inputs are dimensionally rich
Well, that makes arrays a subset of functions. What is still a "yes" to the questions "are arrays functions?"
And yeah, of course the article names Haskell on its second phrase.
It reminds me of a saying I heard from an Italian:
"...and if my Grandmother had wheels she would have been a bike."
> arrays are a notation for address offsetting
That's an implementation detail, though.
No, not when you're designing processes based on a Von Neumann (sequential RAM) architecture. This is the characteristic feature of what the 'array tool' represents.
That depends on the language. I have used (and implemented) languages where arrays are modeled as a function from an index space to some expression. During compilation, this is used to drive various optimisations. For those arrays that need a run-time representation, they may be stored in the classic way (a dense region of memory accessed with offsets computed from indexes), but also in more complicated ways, such as some kind of tree structure. These are still, semantically, arrays at the language level.