Brian Boutel wrote:
>
> Of course it *can* be done, but *should* it be done?
>
> Uncontrolled overloading means that when you see a function application you can't
> immediately see what function is being applied - you see its name but not its
>semantics, because
> there may be many different functions with the same name.
>
> Obfuscating the program source in this way presents a risk of error, and is bad
>language engineering.
>
> What would be gained by allowing ad hoc overloading? If operations on different
>types have similar meaning
> there is a case for defining a new class. If you have existing different functions
>with similar names you can
> qualify them to avoid the ambiguity. When else would you want this feature?
1) Allowing operational parameters to be used.
2) Allow record names to be reused. Most langauges have a special
syntak for record names but haskell does not. Record names are just
treated as selector functions.
3) Allow really really clean systax for functions with compicated
parameters. Try doing this within current haskell.
array (range 1 to 10) ...
array (range 1 to 10 skip 2) ...
array (range 1 to 100 factor 2) ...
with true overlading you can do this my defining multiple range
functions.
data To ; to :: To; to = undefined
data Skip ; skip :: Skip; skip = undefined
data Factor ; factor :: Factor; factor = undefined;
range :: a -> To -> a -> ArrayRange
range x to y = ...
range :: ...
range x to y skip s = ...
range :: ..
range x to y factor 2 = ...
And with a little bit of syntactic sugar this can be made even shorter.
Try doing that with current haskell!
True ad-hoc overloading can lead to unreadable programs if it is
misused. However it can make code more readable and concise if used
properly.
--
Kevin Atkinson
[EMAIL PROTECTED]
http://metalab.unc.edu/kevina/
