5 ms·

You can go the opposite direction: Why do only functions get to refer to themselves in their definitions? ones :: [Integer] ones = 1 : ones There. Tha

You can go the opposite direction: Why do only functions get to refer to themselves in their definitions? ones :: [Integer] ones = 1 : ones There. That's valid Haskell. A non-function value whose definition depends on itself. Haskell doesn't have a rule that functions are privileged, and get to be the only bindings that get to refer to themselves. And that's really handy - though the simple examples like that one are kind of contrived, it can pay off big time in more complex cases.

poizan42 12y ago
Because selfreference is meaningless for something that isn't a function in the usual sense of the word. Your example only shows that "lists" in Haskell really are functions, or at least what you would call an iterator or enumerable in other (non-lazy) languages.
- belovedeagle 12y ago
  Not so at all. As soon as the runtime decides to head-normalize the "second" element of that list, then there are no more thunks left to evaluate; ones ends up being a circular data structure that you could have written in C. Self-reference is no more meaningless in Haskell than it is in C; that is, it's perfectly well-defined, a pointer back onto itself. Cf. Scheme: (define list (cons 1 '())) (set-cdr! list list) The only difference with the Haskell is that it requires no mutation (and the same difference exists between Haskell and C). Insofar as that is the case, I suppose you're right in that self-reference by name requires thunks, which are kind of like functions, but not really...
- tome 12y ago
  It works in OCaml too, where lists certainly are not functions! let rec ones = 1 :: ones;;
  - poizan42 12y ago
    I don't know OCaml, but logically it cannot be an actual realized list as the would take up an infinite amount of memory. Whether or not it acts like a function in the language wasn't really the point - internally it must still be an iterator unless you have a computer with an infinite amount of memory.
    - tome 12y ago
      It's not a function, an infinite list or an iterator. It's a cyclic linked list.

poizan42 12y ago

Because selfreference is meaningless for something that isn't a function in the usual sense of the word. Your example only shows that "lists" in Haskell really are functions, or at least what you would call an iterator or enumerable in other (non-lazy) languages.

belovedeagle 12y ago
Not so at all. As soon as the runtime decides to head-normalize the "second" element of that list, then there are no more thunks left to evaluate; ones ends up being a circular data structure that you could have written in C. Self-reference is no more meaningless in Haskell than it is in C; that is, it's perfectly well-defined, a pointer back onto itself. Cf. Scheme: (define list (cons 1 '())) (set-cdr! list list) The only difference with the Haskell is that it requires no mutation (and the same difference exists between Haskell and C). Insofar as that is the case, I suppose you're right in that self-reference by name requires thunks, which are kind of like functions, but not really...
tome 12y ago
It works in OCaml too, where lists certainly are not functions! let rec ones = 1 :: ones;;
- poizan42 12y ago
  I don't know OCaml, but logically it cannot be an actual realized list as the would take up an infinite amount of memory. Whether or not it acts like a function in the language wasn't really the point - internally it must still be an iterator unless you have a computer with an infinite amount of memory.
  - tome 12y ago
    It's not a function, an infinite list or an iterator. It's a cyclic linked list.