2 ms·

> Data structures, you mean like hashmap, vector, list, sequence? No, algebraic data types: http://en.wikipedia.org/wiki/Algebraic_data_types http://en.wikiped

by andreyf 18y ago

> Data structures, you mean like hashmap, vector, list, sequence? No, algebraic data types: http://en.wikipedia.org/wiki/Algebraic_data_types http://en.wikipedia.org/wiki/Algebraic_data_types

anamax 18y ago
From the article. data Tree = Empty | Leaf Int | Node Tree Tree Here, Empty, Leaf and Node are the constructors. Somewhat similar to a function, a constructor is applied to arguments of an appropriate type, then yielding an instance of the data type to which the constructor belongs. For instance, Leaf has the something like a “functional type” Int -> Tree meaning that giving an integer as an argument to Leaf produces a value of the type Tree. As Node takes two arguments of the type Tree itself, the datatype is recursive. Operations on algebraic data types can be defined by using pattern matching to retrieve the arguments. For example, consider a function to find the depth of a Tree, given here in Haskell: depth :: Tree -> Int depth Empty = 0 depth (Leaf n) = 1 depth (Node l r) = 1 + max (depth l) (depth r) Thus, a Tree given to depth can be constructed using any of Empty, Leaf or Node and we must match for any of them respectively to deal with all cases. In case of Node, the pattern extracts the subtrees l and r for further processing. The explanation of how Leaf, Empty, and Node work make me wonder what happens if I want to use Leaf for some other purpose, outside the context of Tree. It looks like Tree necessarily "leaks", which is a bad thing. The definition of depth doesn't give me any reason why I'd want to use such an inverted definition. I like pattern matching as much as the next person, but it's a tool, not a goal.
- calambrac 18y ago
  Leaf is a data constructor for the type Tree, it's not supposed to be a generally reusable entity, and it wouldn't make sense to treat it as one, just like it wouldn't make sense to treat a constructor in Java as reusable across classes. There's not really even anything there to reuse - it's just a symbol attached to a very small bit of structure, linked to the data type Tree.
  - anamax 18y ago
    If trees are made us using Leaf, Node, and Empty, tree "leaks" names, which is a disaster because lots of things have leaves, nodes, and empty. That's what the explanation seems to say. It's unclear if calambrac's comment is meant to say that trees are actually made using something like tree.Leaf(int) or (more likely) tree() by itself and type disambiguation. One reason why I've never looked seriously at Haskell is that all of the examples that I've seen are basically puns and there's no indication as to how one might build larger programs. I'm sure that there's some way to do so, but I assume that the advocates present the language in its best light.
    - calambrac 18y ago
      Haskell has one of the best namespace/module systems of any language I've ever seen. It doesn't 'leak' these names; they're just the names of the data constructors, they're supposed to be visible. If you need to control access, use the module system. I think it's perfectly legitimate for examples of particular features to omit other features (like modules, in this case).
      - anamax 18y ago
        > Haskell has one of the best namespace/module systems of any language I've ever seen. It doesn't 'leak' these names; they're just the names of the data constructors, they're supposed to be visible. If you need to control access, use the module system. If I have to use modules to hide distinguish tree leaves from other leaves, I'm using modules to do what I get from classes in other languages. Since those languages also benefit from modules .... > I think it's perfectly legitimate for examples of particular features to omit other features (like modules, in this case). I agree that any specific example should be targetted. My point is that none of the Haskell examples that I've seen address large programs.
        calambrac 18y ago
        I mean... you're right, you are using modules to do what you get from classes in other languages. So what? You say this like it's a bad thing, it's not, it's just how this particular problem is solved in Haskell. Different != Horrible. I would argue it's actually a little bit more elegant, in that it takes a problem (namespacing) and solves it one way (modules), rather than having some hybrid package/class system. I'm interested to see the examples you've seen for other languages that do address large programs. I've personally not come across many "How to write Firefox in Python"-style tutorials.
deleted 18y ago
[deleted]

by andreyf 18y ago

> Data structures, you mean like hashmap, vector, list, sequence? No, algebraic data types: http://en.wikipedia.org/wiki/Algebraic_data_types http://en.wikipedia.org/wiki/Algebraic_data_types

anamax 18y ago

From the article. data Tree = Empty | Leaf Int | Node Tree Tree Here, Empty, Leaf and Node are the constructors. Somewhat similar to a function, a constructor is applied to arguments of an appropriate type, then yielding an instance of the data type to which the constructor belongs. For instance, Leaf has the something like a “functional type” Int -> Tree meaning that giving an integer as an argument to Leaf produces a value of the type Tree. As Node takes two arguments of the type Tree itself, the datatype is recursive. Operations on algebraic data types can be defined by using pattern matching to retrieve the arguments. For example, consider a function to find the depth of a Tree, given here in Haskell: depth :: Tree -> Int depth Empty = 0 depth (Leaf n) = 1 depth (Node l r) = 1 + max (depth l) (depth r) Thus, a Tree given to depth can be constructed using any of Empty, Leaf or Node and we must match for any of them respectively to deal with all cases. In case of Node, the pattern extracts the subtrees l and r for further processing. The explanation of how Leaf, Empty, and Node work make me wonder what happens if I want to use Leaf for some other purpose, outside the context of Tree. It looks like Tree necessarily "leaks", which is a bad thing. The definition of depth doesn't give me any reason why I'd want to use such an inverted definition. I like pattern matching as much as the next person, but it's a tool, not a goal.

calambrac 18y ago
Leaf is a data constructor for the type Tree, it's not supposed to be a generally reusable entity, and it wouldn't make sense to treat it as one, just like it wouldn't make sense to treat a constructor in Java as reusable across classes. There's not really even anything there to reuse - it's just a symbol attached to a very small bit of structure, linked to the data type Tree.
- anamax 18y ago
  If trees are made us using Leaf, Node, and Empty, tree "leaks" names, which is a disaster because lots of things have leaves, nodes, and empty. That's what the explanation seems to say. It's unclear if calambrac's comment is meant to say that trees are actually made using something like tree.Leaf(int) or (more likely) tree() by itself and type disambiguation. One reason why I've never looked seriously at Haskell is that all of the examples that I've seen are basically puns and there's no indication as to how one might build larger programs. I'm sure that there's some way to do so, but I assume that the advocates present the language in its best light.
  - calambrac 18y ago
    Haskell has one of the best namespace/module systems of any language I've ever seen. It doesn't 'leak' these names; they're just the names of the data constructors, they're supposed to be visible. If you need to control access, use the module system. I think it's perfectly legitimate for examples of particular features to omit other features (like modules, in this case).
    - anamax 18y ago
      > Haskell has one of the best namespace/module systems of any language I've ever seen. It doesn't 'leak' these names; they're just the names of the data constructors, they're supposed to be visible. If you need to control access, use the module system. If I have to use modules to hide distinguish tree leaves from other leaves, I'm using modules to do what I get from classes in other languages. Since those languages also benefit from modules .... > I think it's perfectly legitimate for examples of particular features to omit other features (like modules, in this case). I agree that any specific example should be targetted. My point is that none of the Haskell examples that I've seen address large programs.
      - calambrac 18y ago
        I mean... you're right, you are using modules to do what you get from classes in other languages. So what? You say this like it's a bad thing, it's not, it's just how this particular problem is solved in Haskell. Different != Horrible. I would argue it's actually a little bit more elegant, in that it takes a problem (namespacing) and solves it one way (modules), rather than having some hybrid package/class system. I'm interested to see the examples you've seen for other languages that do address large programs. I've personally not come across many "How to write Firefox in Python"-style tutorials.

deleted 18y ago

[deleted]