My proposal for the Haskell style of Prelude, Library was
--------------------------------------------------------------
to minimize the number of function names using options.
Thus, we see in ghc-0.26 library
quicksort :: (a -> a -> Bool) -> [a] -> [a]
sortLt :: (a -> a -> Bool) -> [a] -> [a]
stableSortLt :: (a -> a -> Bool) -> [a] -> [a]
I think, it should be like this:
sort :: String -> (a -> a -> Bool) -> [a] -> [a]
--mode
sort mode cp xs = (case mode of
"" -> quick xs
"lt" -> lt xs
"st" -> stable xs
_ -> error "(sort ..): wrong mode"
)
where quick xs =
...
lt xs =
...
stable xs =
...
This implies that if you recently have only one variant of `sort',
still introduce the mode String in the format, to preserve room
for the future versions - if they are likely to appear.
-------------------------------------------------------------------
Alastair Reid writes
> IMHO, this would be a major mistake:
> 1) there is no reasonable way for the compiler to check that you're
> using a sensible string.
> 2) If different implementations add their own sorting functions,
> (ie further magical strings) we'll get code with very subtle
> portability problems (ie it will compile but will fail at runtime)
> 3) programmers despairing of (1) and (2) will add the definitions:
> quicksort = sort ""
> sortLt = sort "lt"
> stableSortLt = sort "st"
> bringing back all the old names but reducing portability
> 4) those string comparisions at the start of every sort are
> inefficient.
--------------------------------------------------------------------
I do not agree with this.
First, a very little improving: let the above "case" be
(case mode of "lt" -> lt xs
"st" -> stable xs
"q" -> quick xs
_ -> lt xs
)
where lt xs =
...
stable xs =
...
Now the counter-argumentation:
4)
In the worst case of the default mode, we have 3 comparisons
of kind
" first letter of mode is 'l' "
- just 3 elementary steps - before starting the real sorting.
Are you saying seriously that this would slow down the program ?
As they say, "Effectivity is a matter of getting the costs into
proportion" ...
1)
With this new "case", the sorting will perform correct for *any*
mode string.
Besides, are we so frightened when, say (logarithm x) yeilds
run-time error report on x = 0 ?
2)
If an implementator wishes to add other modes, of course, she
should put a *new function* with all its modes (and now they
may partly repeat the old ones) into the
* implementation-dependent library*.
Standard prelude is not a subject for the implementation changes.
Am I missing something ?
The suggestion was only for Standard prelude or Standard library.
Standard modes may change only with the changes of the standard.
No portability problems arise here.
> 3) programmers despairing of (1) and (2) will add the definitions:
...
> sortLt = sort "lt"
...
> bringing back all the old names but reducing portability.
Portability is preserved, as it was marked earlier.
Besides, applying sortLt instead of sort "lt",
add23 instead of (add 23) or (+ 23),
...
is evidently a bad syntax, bad style.
Standard prelude should not provoke user to copy a bad style.
Sergey Mechveliani
[EMAIL PROTECTED]
