[Haskell-cafe] Re: Overloading functions based on arguments?

[Sterling Clover]

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  
horizontal axis?

> 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  
instance.

Cheers,
Sterl.