> > I find that if you make liberal use of higher-order constructs and
> > modularize your code, then the need to do explicit binding is
> not so much of
> > a problem. Then again, I am the sort of person who uses "let"
> and "where"
> > whenever he can to name subexpressions as well...
>
> But the point is I would like the type system to AUTOMATICALLY do this
> for me so that I don't have to memorize/lookup a bunch of higher order
> functions. True ONCE you know them all they are not difficult to use
> but to a new programmer all these (seemly unnecessary) high functions
> can make doing the simplest task quite difficult. So the new programmer
> will just use the do....
Doesn't it also make it easier on new users that things with different
semantics have different names? It seems like true ad hoc overloading would
only make things more confusing; certainly the error messages would become
more difficult to understand.
It would eliminate the need to think up new names in some circumstances, but
if you compare the amount of time spent in doing that when you write a
program, to the amount of time you might spend trying to figure out why your
program won't compile, or worse, compiles but runs incorrectly.... (I have a
hard enough time, sometimes, figuring out what the type of something is in
the presence of functors and MPTC!) Experiential reports and empirical data
would be valuable here.
> This is why I belive in true adhoc overloading.
>
> 1) so that you don't have to make up names just reuse the old ones
> 2) make using standard library functions easier to use because there
> will be a lot fewer names to lookup/memorize.
1) For intermediate values which are not so important, you can get around
inventing new names by using scoping and shadowing. For bigger things which
you want to identify, you can either use qualified module identifiers, or
Haskell's type classes which at least let you establish and codify a
motivation for using the same name for distinct things (namely, that their
types are equivalent under a particular relation). That's already four
mechanisms for dealing with overloading.
2) It would also be useful if documentation were easier to access and use
(which has been a recent topic).
I must admit that I don't like the idea of determining a value based on its
type, at least in a language like Haskell. For me, functional programming is
about how to write programs combinatorially, and justifying your hypotheses
by encoding their proofs; so a type is something that ought to be uniquely
derivable from a value, not the other way around. Haskell's class system
already goes too far against this idea for my taste.
I know that some people do not feel this way, however.
--FC
