[Haskell-cafe] Re: Overloading functions based on arguments?
s.clover at gmail.com
Thu Feb 19 23:21:19 EST 2009
On Feb 19, 2009, at 9:09 AM, John A. De Goes wrote:
> Let's try a little test:
> 1. If the parameter is a tree, what do you think "flatten"
> would do?
I would imagine that it would be "join" on trees -- i.e. take a tree
of trees and turn it into a tree. But perhaps it would be arbitrarily
deep. Or perhaps it would turn a tree into a list, but I would of
course prefer toList for that.
> 2. If the parameter is a list, what do you think "flatten"
> would do?
Since a list is already flat, it couldn't possibly turn it into a
list -- but again, it could perhaps be "join" or it could be
"deepJoin" or maybe if it was a list of numbers that represented a
signal, it would smooth out peaks beyond standard deviation, but
maybe it would do that treating the numbers as a time series or
perhaps it would do that treating the numbers as coefficient to a
series of trigonometric functions.
> 3. If the parameter is a Style (possible a composite Style
> consisting of other styles), what do you think "flatten" would do?
If the style included colors, perhaps it would mute them? Or, maybe,
it would mean, as you intended, join. And if a style may consist of
other styles, then isn't it, properly speaking, a variant of a tree
to begin with?
> 4. If the parameter is a Bezier curve, what do you think
> "flatten" would do?
One would imagine, produce a straight line. But would this line be
between the original endpoints, or would it be a projection onto the
> My guess is that we would come to the same conclusions for (1) -
> (4). The name "flatten" is a perfectly good name for all of these
> operations, because the domains are distinct, and because using
> that name suggests the correct meaning to you. (Note use of the
> word "suggests" -- like an analogy or parable, you're likely not
> going to know exactly what the function does just by reading its
> name, but you'll be in the ballpark and have an intuition about it,
> which is extremely valuable.)
In three cases, depending on what you intended "flatten" to mean
(I've been a bit provocative, but honestly I do have no idea), then
the domains may not be distinct, because "join" is an operation that
they do properly have in common. And no, the name doesn't suggest one
clear meaning -- what does, generally, suggest a single clear meaning
to me, is a good type signature, but since I could no longer query :t
"flatten" in GHCI and get a single response, I would be, I'm afraid,
somewhat at sea -- even more so if in some cases flatten was a
typeclass operation, and in others not. Or, worse yet, if flatten was
declared as a typeclass operation in one place, defined on lists in
another, and in a third, lists were given an orphaned Flattenable
More information about the Haskell-Cafe