On 1 Jun 2000, Ketil Malde wrote:
> I could accept "mode flags" if the algorithm is extremely similar,
> e.g. passing a comparator function to a sort is a kind of mode flag
> (think ordered/reversed) which I think is perfectly acceptable.
> Having flags indicating algorithm to use (sort Merge (s:ss)) is IMHO
> silly.
There are cases where functions taking mode arguments might be more easily
usable than duplicate functions (note I'm not necessarily arguing this is
one of them) because various things can be done on the mode value (eg,
equality tests, automatic enumeration, etc) which can't be done on the
functions themselves. The following bizarre code (which runs in Hugs Jan
98 at least) indicates the sort of thing
import Maybe
data FType = F | G | H deriving (Eq,Ord,Enum,Show)
operation::FType -> a -> Maybe a
operation H a = Just a
operation _ _ = Nothing
tryUntilSucceedWithOperation::Eq a=>a->a
tryUntilSucceedWithOperation x
=(fromJust.head.dropWhile (==Nothing).
(map (flip operation x))) (enumFrom F)
where operation is the library code and tryUntil... is the end-user code.
(Obviously operation would be something with a less predictable
succeed/fail pattern.) Then adding a new method with FType J, say, just
requires slotting J into the appropriate position in FType and everything
else works automatically. I can half see how you might be able use typed
mode arguments to do some things in a much simpler way than with complete
different functions, but I haven't the time to resolve it to a convincing
real world example, so I may be wrong :-)
___cheers,_dave________________________________________________________
www.cs.bris.ac.uk/~tweed/pi.htm|I shoulda realised building the
email: [EMAIL PROTECTED] |memory allocation subsytem with
work tel: (0117) 954-5253 |--with-malicious-ai was a bad idea.