Arrays are objects (allocated memory and metadata if you will). The function is what takes the array and an int and returns an item.

▲ repsilat an hour ago | parent | next [-]

Yeah I guess a c++ programmer might say `std::array::operator[]` is a function (or method, whatever), just like `std::array::size` is. And that identifying the array with just one of those functions (or even the collection of all methods offered) is to miss the point -- not just contiguous indices, but contiguous storage. A red-black tree with added constraints is not an array.

TFA does allude to this. An "array indexing function" that just met the API could be implemented as an if-else chain, and would not be satisfactory.

▲ hekkle 2 hours ago | parent | prev [-]

In Object Oriented programming, yes, arrays are objects and the functions are a property of another object that can perform instructions on the data of the Array Object.

Similarly in Lisp, (a list-oriented language) both functions and arrays are lists.

This article however is discussing Haskel, a Functional Language, which means they are both functions.

▲ Jtsummers 2 hours ago | parent [-]

> Similarly in Lisp, (a list-oriented language) both functions and arrays are lists.

In which Lisp? Try this in Common Lisp and it won't work too well:

  (let ((array (make-array 20)))
    (car array))

What is the car of an array? An array in Lisp (since Lisp 1.5 at least, I haven't read earlier documentation) is an array, and not a list. It does not behave as a list in that you cannot construct it with cons, and you cannot deconstruct it with car or cdr.

	▲	hekkle an hour ago \| parent [-]
		To quote John McCarthy "Since data are list structures and programs are list structures, we can manipulate programs just like data." Yes, I know most people consider it to be a functional language, and some variants like 'common lisp' make that more explicit, but the original concept was markedly different.