To my suggestion on the mode argument for some standard functions
>> quotRem ... divRem ...
>>
>> And we can hardly invent the mode type better than Char,
>> because any specially introduced mode types bring the long names.
>>
>> quotRem 'n' x (-3) looks better than the pair quotRem & divMod,
>> and
>> quotRem QuotRemSuchAndSuch x (-3)
>> looks worse than quotRem & divMod.
D.Tweed <[EMAIL PROTECTED]> writes on 31 May 2000
T> [..]
T> (2) Having an enumerated type is better because it will cut down on
T> `accidental namespace collisions' if I cut and paste something which
T> expects mode character 'n' to mean one thing into a function call where it
T> means something completely different.
I knew of the namespace collision effect.
But one has to choose between the bad and worse.
And in any case, there remain too many ways to error.
We also may paste
True :: Bool instead of False
(the type design does not help),
x / 0 instead of x / 2,
take n xs instead of take (-n) xs
We also may forget to write a program and try to use it.
Generally, concerning the mode argument: looks like the Haskellites
avoid it. I am just trying to understand what is going on.
Why people do not complain on the mode argument outside of Haskell:
`zip -r ...' `unzip -t xxx.zip' `tar xvfz xxx.tar.gz'
?
One may paste -x instead of -t, with unpleasant effect.
Also in any application each respectful function has about a douzen
of the sensible mode values.
And it is definitely not good to have several functions in the
interface instead of several mode values for one function.
T> To be fair, there are two minor cons that haven't been mentioned:
T> [..]
T> (2) These enumerated types presumably have to be added to explicit import
T> lists, even if you're only using the most common type. Much existing
T> script breakage!
It was said, Haskell-2 does not care for the old code.
And I mean only Haskell-2.
Patrik Jansson <[EMAIL PROTECTED]> writes on 31 May 2000
J> On the contrary - you only need one character N instead of threee 'n' if
J> you use a datatype with two constructors N and (whatever you like for
J> the other case).
J> But the length of the argument is not that interesting here - you can have
J> long names for the constructors of the "mode" datatype and still use short
J> local abbreviations.
'n' :: Char does not hold a name in the constructor name space.
And `N' hardly would do. There may be many other constructors wanting
short names.
Suppose there are about 10 functions to provide with the mode.
It will looke like this
quotRem :: ...=> Mode_quotRem -> a -> a -> (a,a)
sortBy :: Mode_sort -> Comparison a -> [a] -> [a]
...
data ModeQuotRem = QuotRem_minRem | QuotRem_positive | QuotRem_other
deriving(Eq,Ord,Enum,Show,Read)
-- contrived
data Mode_sort = Sort_quick | Sort_merge | Sort_insert | Sort_other
deriving(Eq,Ord,Enum,Show,Read)
...
Again, `Positive' would not do, it should be something like
QuotRem_Positive, and so on.
For example, my program contains many expressions like
f x y b = myRem 'c' ((myRem '_' x b)*(myRem '_' y b)) b
Now, it has to be, maybe, remP = rem QuotRem_positive
remO = rem QuotRem_other
f x y = remP ((remO x b)*(remO x b)) b
Maybe, Char is better?
------------------
Sergey Mechveliani
[EMAIL PROTECTED]
