Names for small functions: just say no... Re: Data.List.join

[Jon Fairbairn]

On 2006-11-10 at 00:32+0100 Udo Stenzel wrote:
> Jon Fairbairn wrote:
> > But not all patterns deserve names. To give a
> > reductio-ad-absurdam sort of analogy, suppose someone looked
> > at a lot of C and came to the conclusion that “for (i=0,
> > i++, ...)” occurred in 90% of programmes.  Were they to
> > reason that it would be worth #defining a macro FORI(...)
> > and using that instead, I suspect that the suggestion would
> > be roundly dismissed.
> 
> Well, I presume you actually meant 'for( i=0; ... ; i++ )', an error
> which would have been avoided by using a macro. 

If I don't know the order of the clauses in C loops, a macro
isn't going to help much: I shouldn't programme in C full
stop. Fortunately I don't, so that's OK.

Unless you are seriously arguing that embedding the name of
the loop control identifier in a macro is a good idea, it
seems I pared down my "obviously silly" example to the point
where the sillyness was no-longer obvious.  I was trying to
be too concise. I meant to say that "If someone found that
90% of control variables are called “i”, that wouldn't make
it a good idea to have a macro “FORi” that expanded into
“for (i,...)”" -- the incrementing by one was incidental.

> Also, a macro would have liberated you of the choice
> between '++i' and 'i++', where '++i' is often more
> efficient (at least in C++).  And in C++, you're
> encouraged to use std::for_each anyway, which is the C++
> way to spell 'mapM_'.  Which would make your point kinda
> moot, but I'm not really convinced that arguments from a
> souped up assembly language can be used to make a point
> about Haskell.

Evidently not. C is so clumsy that I messed up my trivial
and silly example completely.

> > Of course not, but you have to be careful what you deduce
> > from the old code, particularly if you are reasoning from
> > "most code is like this", because that doesn't tell you
> > whether most code should be like that or most code should
> > have been written differently.
> 
> Exactly!  To state it explicitly:  it seems, 'intersperse' is either
> used at type 'String' or in conjunction with pretty printing.  Or in
> other words, either with pretty printing or with ugly printing.
> Therefore, the right thing to do is not to provide an ugly printing
> idiom, but to improve Text.PrettyPrint to the point where it is easier
> to use than plain strings.

Right. If there is a problem, I don't think it's that
“intercalate foo” is currently spelled “concat . intersperse
foo”, and if there is something deeper we can do to mend the
problem, I'm in favour of it. Actually, I'd start by
deprecating Show, because for machine readability it's not
efficient and for human readability it's too simplistic.

 Jón


-- 
Jón Fairbairn                              Jon.Fairbairn at cl.cam.ac.uk