On 01-Jun-2000, S.D.Mechveliani <[EMAIL PROTECTED]> wrote:
> Why people do not complain on the mode argument outside of Haskell:
> `zip -r ...' `unzip -t xxx.zip' `tar xvfz xxx.tar.gz'
> ?
People do indeed complain about Unix's habit of using cryptic option
sequences like `-r', `-t' or `xvfz'. Why do you thing long options
(e.g. `--recursive', rather than `-r') were invented?
Short options like `-r' are useful for interactive use.
But if you're programming (e.g. writing shell scripts),
then you really ought to use the long versions instead,
since it makes the code much more readable.
Unfortunately for historical reasons the long options are not as
portable as the short options, for many standard Unix commands.
But hopefully that will change over time.
> 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.
Yes, but it is also far from self-expanatory. With a constructor
name, in a suitable environment you could just click on the
constructor name and the environment would immediately pop up the
declaration and documentation for that constructor and the type that
it belongs to. Such an environment need not be particularly
sophisticated, e.g. the tags support in vim and Emacs is sufficient.
But with `Char', it would be much much more difficult.
Including `Char' in a function signature provides no information
for the user about what the meaning of that argument is.
It is IMHO bad style.
> 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.
This is a problem with Haskell, IMHO.
Mercury allows overloading of constructor names, so in Mercury you
could use just `Positive' rather than `QuotRem_Positive'. The type
checker will resolve the ambiguity whenever possible. Note that if
such a constructor was used as the first argument of a function like
the `quotRem' and `sortBy' functions you've declared above, there
would be no ambiguity.
> 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?
No, IMHO Char would definitely not be better.
In this case, I think separate functions would be best,
a single function with a properly typed mode argument second best,
and a single function with a `Char' mode argument worst.
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
