[Haskell-cafe] Shrinking the Prelude: The "categorical" approach

[Brian Hulley]

Imam Tashdid ul Alam wrote:
> hi guys,
> I was just wondering if anyone is interested is a
> "quasi"-project of rewriting the Prelude (only
> shrinking it as measured by the total number of names
> imported, read along...)
> the idea is (just to be substantially different in
> approach) to develop an "alternate history" of
> Haskell.
> take map for example, and fmap, I don't think they
> should be named different (fmap is ugly, not
> suggestive, and conceptually the same).
> mplus could be renamed (++) (they are conceptually the
> same

I suggest that all functions in classes be given actual names and ASCII 
symbolic names could be defined outside the class as an additional 
convenience eg:

    class Monad m => MonadPlus m where
        mzero :: m a
        mplus :: m a -> m a -> m a

    (++) = mplus    -- 'convenience' name

I think people forget that ASCII symbol names which look intuitive to them 
when they are writing a library or paper, can be very confusing for people 
who need to use many libraries (with consequent explosion of obfuscatory 
symbols) in a project, look terrible when qualified, and make code difficult 
to read because of the need to find/remember precedences and associativity. 
(Note that Haddock does *not* supply this info, you need to look at the 
actual source code of the library to find it out.)

> , mzero looks odd, name it empty, or simply zero)

What about (mempty) from Monoid or (empty) from Data.Sequence or 
Control.Applicative? Either these are in some way the same thing as mzero, 
or else they are different in which case either qualified imports would be 
needed everywhere (not necessarily a bad thing) or different names like the 
ones we already have, are needed.

> although I think concat should be replaced by msum (or
> the other way around preferably :) ? msum is a bad
> name) I am somewhat confused by join. concat seems to
> match join's type but I don't think the ideas
> coincide.
> and so on. in particular, we would want:
> * no backwards compatibility. the Prelude as is it, is
> good enough. we are defining a new module.

Starting with a clean slate seems a good idea, especially to get rid of 
lispy names like (cons), (snoc), (null) and replace them with something 
self-explanatory like (pushL), (pushR), (isEmpty).

> * clean categorical hierarchy of type classes
> (category theorists wanted!) promoting uniformity.

This would be great. However it is a question to me whether it is even 
possible to organize everything in a single hierarchy. Eg look at the 
problems with trying to reorganize Num, or standard OOP problems with 
hierarchies in general. Since there are multiple ways of looking at a 
domain, it is likely there will need to be multiple hierarchies which will 
probably not interact so well.

> * cleaner names. foldl1 means nothing. absolutely
> nothing. what's the 1 for?

A while back I suggested using capital letters for suffix to distinguish the 
functionality (fold) from the variant (L == left). Perhaps (foldl1) could be 
renamed (foldLN) ie fold + left + non-empty or (foldLO) for fold + left + 
occupied.

> * our Prelude only contains typeclasses, datatypes,
> and functions of utmost conceptual (and semantic, such
> as error, undefined and seq) importance, everything
> else goes to other modules. our Prelude is not going
> to be a place for "convenient" declarations.
> * the suffix method of naming (liftM2) is considered
> messy. we would prefer a seperate module (promoting
> qualified import).

In the particular case of *M functions, I quite like the existing naming 
since it's clear that it's a monadic function. However I'd agree that names 
like (newIORef) are an abomination, that should be replaced by (Ref.new).

> this is a fun project. we will not rewrite the
> Prelude, we'll merely rename it. I would suggest the
> name TheOtherPrelude to make our intentions clear. the
> conveniences (like concatMap) goes to
> TheOtherPrelude.Extension. I suggest we do it on the
> wiki. anyone interested just open a page with your
> name of choice. I am not doing it only because there's
> no point doing it if no one's interested.

Good luck with this. For my own project, I re-implemented FingerTree's so I 
could use my preferred naming style (and also as an exercise following the 
excellent tutorial-style FingerTree paper), and wrote some trivial wrappers 
for a few other modules eg Data.IORef, Data.Unique so that I could use 
Ref.new, Unique.new etc.I think it would be quite a big task to refactor the 
entire code base according to a clean hierarchy of type classes, and also a 
task I can't really help with since I'm not familiar enough with category 
theory at present, but certainly it would be a worthwhile endeavour imho,

Brian.
-- 
http://www.metamilk.com