3 ms·
Another way to make that argument is that arrays are an exponential type and therefore are logically equivalent to functions. That is, the cardinality of the t
by ben509 7y ago
Another way to make that argument is that arrays are an exponential type and therefore are logically equivalent to functions.
That is, the cardinality of the type Array<T> is exactly the same as the cardinality of the type Function<Integer, T>. Any pure function that takes an integer and returns T can be replaced with an array, and vice versa.
Same deal with Map<K, V>, that's logically equivalent to Function<K, V>.
Two problems:
1. People don't think in category theory, they have containers to contain thinks and functions to calculate things.
2. People are right, the function call really is doing something different than an array index. If a thing is different, it should look different.
- monocasa 7y ago> People are right, the function call really is doing something different than an array index. What is fundamentally different?
- monocasa 7y agoI mean, really? Isn't the whole point of the STL to paper over those differences and supply functions with similar semantics for those kind of accesses regardless of the data structure? About the only reason I can see for array access syntax existing is that in the days before optimizing compilers, people would have lost their mind if array access called into a function each time (with good reason). It took manual programmer intervention to hint what compilers couldn't cleanly infer themselves. We don't need that anymore.
- ben509 7y agoOne is looking up a value, while the other is (in most of these languages) executing a subroutine. While they are mathematically equivalent, in these languages they are doing different things. Function application and array access are two different concepts the symbols are trying to convey to a programmer. This is why, e.g., in Haskell where a string is literally a list of characters, they nevertheless have a different syntax for the two.
- monocasa 7y agoI mean, Haskell literally defines array access in terms of a function. > Haskell provides indexable arrays, which may be thought of as functions whose domains are isomorphic to contiguous subsets of the integers. https://www.haskell.org/onlinereport/haskell2010/haskellch14.html https://www.haskell.org/onlinereport/haskell2010/haskellch14... The fact that strings are different seems to have more to do with the ergonomics of strings rather than arrays.
- username90 7y agoYou are wrong, collections are mutable and hence different from functions. Index operators are expected to return l-values while functions are not, that difference is extremely important so is worth the compiler overhead in order to make code easier for users to read.
- ben509 7y agoYou can't analyze this stuff with the specifics of a language in mind, or even assume there's a heap, let alone talk about what compiler optimizations apply. Because if we try to do that, what's our common basis of understanding? You could be talking about gcc and I'd be talking about clang and we'd go in circles. If we limit ourselves to the math, we can agree that a type is a domain that contains certain values and excludes others. But we have to throw out mutability because values, by mathematical definition, are immutable. And once we've got a clear notion of what values are, we can then talk about how many values there are in a type. And that's where I'm coming from in claiming functions are equivalent to containers.