[eeps] Multi-Parameter Typechecking BIFs

Richard O'Keefe <>
Wed Feb 25 02:51:07 CET 2009

On 24 Feb 2009, at 11:18 pm, mats cronqvist wrote:
>> Why don't I see people arguing in the Haskell mailing list
>> that the inclusion of guards in Haskell was a mistake?
>  because they're all smarter than me? all 3 of them.

Many of them are much smarter than me.
But the Haskell mailing list has *far* more than 3 posters.
Many of them are beginners.
>> Indeed there is.  But you cannot use [things introduced by
-type declarations] in guard tests
>> or patterns.
>  No. But it would be nice if you could.

Hooray!  We agree!
>> Let me offer the following recommendation to Real Programmers:
>> unless and until something better (such as abstract patterns,
>> or something that integrates -type declarations with guards)
>> is provided, avoid "bare" type tests in favour of your own
>> type test macros whenever it makes sense to do so.  By doing
>> that, you will be saving yourself work and making your code
>> more readable.
>  Professional Programmers (here defined as people that write programs
>  because the get paid for it, and not because they are interested in
>  it) don't read mailing lists, blogs or books about programming.

In that case, they are what Ledgard & Tauer called P-sub-A
programmers:  people who *think* they are professionals but
are really amateurs.  For the record, I used to be paid to
write programs, have occasionally been paid since, and have
colleagues here with plenty of industry experience, and we
all read books about programming when we were being paid to
write programs.  (Come to think of it, if anyone wants to pay
me to write code now, let me know.)  _Somebody_ reads Martin
Fowler and all those Java books...


>> [...]
>> It's the simple fact that types in patterns make patterns *bigger*,
>> and therefore harder to read.
>  A fact, but disingenuous. One needs to compare
> bla(FooBlaBaxBar, FooFooBlaBaxBar, LaDiDaBaxBar, FooFooBlaBazBar,
>    BlaBlaaBarBar, FooFooBlaBurpBar)
>  when is_integer(FooFooBlaBaxBar), is_atom(FooFooBlaBazBar) ->
> to
> bla(FooBlaBaxBar, FooFooBlaBaxBar::integer, LaDiDaBaxBar,
>    FooFooBlaBazBar::atom, BlaBlaaBarBar, FooFooBlaBurpBar) ->
>  It seems obvious to me which form is easier to read.

Why yes.  It is.  The first one!  The second one is such a
squished up blob that I can't see the type tests.  The first
one is **much** clearer.  Now had you written

	bla( FooBlaBaxBar
	   , FooFooBlaBaxBar     :: integer
	   , LadDiDaBaxBar
	   , FooFooBlaBazBar     :: atom
	   , BlaBlaaBarBar
	   , FooFooBlaBurpBar
	) ->

the case would have been otherwise, but I daresay you will tell
me that Real Programmers don't write that way either.  I would
still regard

	bla( FooBlaBaxBar
	   , FooFooBlaBaxBar
	   , LadDiDaBaxBar
	   , FooFooBlaBazBar
	   , BlaBlaaBarBar
	   , FooFooBlaBurpBar
	) when
as pretty clear, and in some ways clearer, because when I'm
looking at the head, if the names are well chosen, I can
probably _tell_ that something is supposed to be an integer
and really don't want to be distracted by what's _to me_ (but
not the compiler) a redundant ::integer.

>  To get back to the topic, the EEP at hand does nothing for code like
>  this, and is IMO just bloat.

Again, we agree.  Now the sun is shining in my office (actually
a flourescent light, the real sun is hidden by clouds), the
birds are singing (no, I think it's a lawn-mower), and spring is
here (actually it's autumn).  But I _am_ happy we agree about
multi-parameter typechecking BIFs.

More information about the eeps mailing list