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.
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).
> 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.
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.
> I mean... you're right, you are using modules to do what you get from classes in other languages. So what?
My point is that languages that have classes also seem to need modules. Do haskell's modules address the problems that addressed by the combination of classes and modules in other languages? Does Haskell somehow avoid those problems? Is there some other mechanism?
> I'm interested to see the examples you've seen for other languages that do address large programs.
Examples of modules can be trivial yet demonstrate why modules might be useful for large programs.
Haskell isn't object-oriented, so there aren't any little namespaces (classes) running around that themselves need to occupy a namespace (package). So modules are enough.
The Haskell wiki entry on modules is short, pretty complete, and has plenty of examples:
>>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.'
>Non sequitur? Where is the problem. Try
> data MyMaybe a = Just a | Nothing
Huh? How does that create a tree instead of a banana?
Actually, it's completely unclear what that example is doing. I'd guess that it's specifying a new name and a corresponding value, but I'm not sure which name and what kind of value.
The Just and Nothing that he's defining for his MyMaybe are completely different things from the Just and Nothing used for the Maybe that ships in the Prelude. MyMaybe may as well be a banana for all Prelude.Maybe cares.
I want to use them so I don't have to write very much code, so that I can easily reason about my program by directly substituting symbols with their definitions, so that I can use pattern matching against instances of that type, so that I can group them into type classes and know what operations I'll have available to work with them... etc.
It's more or less the haskell version of a struct or a public class with fields and no methods, except that you can specify more than one shape for the same type.
data MyMaybe a = Just a | Nothing
...means in Java speak "MyMaybe<a> is an abstract generic superclass with a final singleton subclass Nothing<a> having no fields, and a final subclass Just<a> having one field of type a"
You then write functions that take that data and use it.
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.