5 ms·

Exactly. Array indexing with [] feels ok to me. > someList(0) /* instead of */ someList[0] This is worse. How do you disambiguate that from a func

• cwzwarich 7y ago
  OCaml uses .() for array access.
  • aloknnikhil 7y ago
    Right. The difference being the "." The article proposes using basic function call syntax. That makes no sense to me. And with .(), you now have 3 characters to type instead of 2 with []. Obviously all of this is pedantic, but then again so is the article.
    • jsjolen 7y ago
      All of what the author said is what Scala does (author likes Scala). I've written a decent amount of Scala, it's fine. I've also written a lot of Common Lisp, where array access is done using aref. That was also fine.
• monocasa 7y ago
  If it is a list, access like that is a function. Even in the context where it's an array with the depedence we have these days on function inlining, it could still be a function fn someArray(offset: usize) -> T* { self.base + (offset * T.size) as T* }
  • 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 ago
        I 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 ago
        One 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 ago
          I 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 ago
      You 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 ago
  I think .get would be more plausible. It's just strange that we can't use [] for indexing, which is an operation that can apply to any container, but << and >> must be reserved for bit-shifting. If I'm adding shifting to a new language, I'm inclined to use functions just so it's clear what's going on, and to put operations like rotation on an even footing. Also, I don't think people have an intuition for the precedence of shift operators, which makes them less useful.
• Someone 7y ago
  Some language designers would argue that, conceptually, it is a function call, especially in languages that don’t allow mutations to data structures. foo = [10,20] Func foo(i) = switch(i) case 0: return 10 case 1: return 20 default: return nil
  • beeforpork 7y ago
    That. Exactly.
• beeforpork 7y ago
  > How do you disambiguate that from a function call? It's now just abusing () You don't. If you apply an integer to an array, it will return an entry. To me, it makes perfect sense to use a(i) instead of a[i]. In fact, in case you need some more complicated data structure to organise your data one day, you could switch to a function call for lookup without rewriting the code that uses a(i). The question is not 'how do you disambiguate?', but 'why do you want to distinguish?' Because an array is just a special case of a function that maps an integer to something else. It is logically not different from a function with a large contiguous switch statement.
  • username90 7y ago
    > To me, it makes perfect sense to use a(i) instead of a[i]. I disagree. Square brackets links to memory, paren just returns data. Of course you could implement the paren function to return a reference, but it makes the code a lot harder to read since that is not the normal case. See comparison: a[i] = 3; or a(i) = 3;