Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Are arrays functions?

futhark-lang.org

Post reply on HN
Print view View original

11–20 of 145 posts

Re: Are arrays functions?

#11

Post by stackghost »

It makes obvious sense to consider an array as a function with the index as its input argument and the element its output, i.e. f(x) = A[x]... but this isn't the first time I've encountered this and I still don't see the practical benefit of considering things from this perspective.

When I'm writing code and need to reach for an array-like data structure, the conceptual correspondence to a function is not even remotely on my radar. I'm considering algorithmic complexity of reads vs writes, managed vs unmanaged collections, allocation, etc.

I guess this is one of those things that's of primary interest to language designers?

Re: Are arrays functions?

#13

Post by lukebitts »

shevy-java wrote: post #10

> Haskell provides indexable arrays, which may be thought of as functions whose domains are isomorphic to contiguous subsets of the integers. > I found this to be a hilariously obtuse and unnecessarily formalist description of a common data structure. Well it is haskell. Try to understand what a monad is. Haskell loves complexity. That also taps right into the documentation. > I look at this description and think tha…

Some people really do look at a painting and see only brush strokes huh

Re: Are arrays functions?

#14

Post by Nevermark »

Arrays and structures are functions.

And all three are tuple [input, output] pattern matches, with the special case that in “call/select tuples”, input is always fully defined, with output simply being the consequence of its match.

And with arrays, structures and overloaded functions being unions of tuples to match to. And structure inputs (I.e. fields) being literal inline enumeration values.

And so are generics.

In fact, in functional programming, everything is a pattern match if you consider even enumeration values as a set of comparison functions that return the highly used enumerations true or false, given sibling values.

Re: Are arrays functions?

#16

Post by magicalhippo »

nomel wrote: post #3
SanjayMehta wrote: post #2

Everything is a function. Next question?

For the downvoters, I think giving examples of what's NOT a function would start an interesting conversation, especially if you don't know how it could possibly be interesting!

For me, a x86 interrupt service routine that services a hardware interrupt[1] doesn't strike me as something I'd consider a function. It shouldn't return a value, and it typically has side effects. So why is it a function?

I mean trivially you could say it's a function from (entire machine state) to (entire machine state), but typically we ignore the trivial solution because it's not interesting.

[1]: https://alex.dzyoba.com/blog/os-interrupts/

Re: Are arrays functions?

#17

Post by thomasahle »

What about replacing

> Haskell provides indexable arrays, which may be thought of as functions whose domains are isomorphic to contiguous subsets of the integers.

with

> Haskell provides indexable arrays, which are functions on the domain [0, ..., k-1]?

Or is the domain actually anything "isomorphic to contiguous subsets of the integers"?

Re: Are arrays functions?

#19

Post by hekkle »

hahahahhaah wrote: post #15

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

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.

Re: Are arrays functions?

#20

Post by tialaramex »

stackghost wrote: post #11

It makes obvious sense to consider an array as a function with the index as its input argument and the element its output, i.e. f(x) = A[x]... but this isn't the first time I've encountered this and I still don't see the practical benefit of considering things from this perspective. When I'm writing code and need to reach for an array-like data structure, the conceptual correspondence to a function is not even remote…

Well for example this insight explains Memoization

https://en.wikipedia.org/wiki/Memoization

If you know that Arrays are Functions or equivalently Functions are Arrays, in some sense, then Memoization is obvious. "Oh, yeah, of course" we should just store the answers not recompute them.

This goes both ways, as modern CPUs get faster at arithmetic and yet storage speed doesn't keep up, sometimes rather than use a pre-computed table and eat precious clock cycles waiting for the memory fetch we should just recompute the answer each time we need it.

Post reply on HN