[eeps] Multi-Parameter Typechecking BIFs

[mats cronqvist]

"Richard O'Keefe" <ok@REDACTED> writes:

> On 23 Feb 2009, at 10:59 pm, mats cronqvist wrote:
>>> "Oops there is a problem here,
>>> so let us imagine that it has been solved."
>>
>>  you're a very weird guy. (that's a compliment.)
>
> My daughters say the same thing.
> I try.
> Ying tong iddle I po!
> For a good time, visit
> http://www.thegoonshow.net/downloads/other/what_time_is_it_eccles.mp3
>
>>  Separating the pattern match from the condition is bad. The 'when'
>>  keyword should have never been introduced.
>
> There are conditions that pertain to *one* thing.
> It may make sense to put those in the pattern, though I doubt it.
> There are conditions that relate *more than one* thing.
> It is an essential property of such conditions that there is
> no one place in the pattern where they belong.
>
> Take the example
>
> 	max(X, Y) when X >= Y -> X;
> 	max(X, Y) when X =< Y -> Y.
>
> (Yes, you do see the influence of Dijkstra in the way that's
> written.)  Which argument would you attach "X > Y" to?

  neither, obviously. IMO, it should be written with a case.

> 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.

>>>>> Where does it say {M,F,A}::names_a_function?
>>
>>  Mmmm... nowhere?
>
> BUT IT ***SHOULD***!
>
>>>>> This is a very very low level way of describing what you want.
>>
>>  If you say so.
>
> This is not a matter of opinion.
> The Erlang type tests are as low level as Erlang lets you get.
>
>>  Meh. This discussion is about
>> f(..., {D::integer,M::integer,Y::integer}, ...) -> ...
>>
>>  vs.
>> f(..., {D,M,Y}, ...)
>> when is_integer(D),is_integer(M),s_integer(Y) -> ...
>
> No it isn't.  
>[...]
> What we are discussing is a proposal to allow
> 	{D,M,Y} .... when is_integer(D,M,Y)
> 	{M,F,A} .... when is_atom(M,F), is_integer(A)
> 	{X,Y,Z} .... when is_float(X,Y,Z)
> The subject _is_ "Multi-parameter typechecking BIFs" after all.
>
> What does that proposal buy us?
> The ability to say a tiny amount of typing when
> more than one variable coincidentally happens to
> need the same type test.
>
> That's it.

 I sit corrected. And, for the record, I think the EEP is pretty
 worthless. 

>>  Macros. Wonderful. Actually, there is a way to declare types;
>> -type(date() :: {integer(),integer(),integer()}).
>
> Indeed there is.  But you cannot use them in guard tests
> or patterns.

  No. But it would be nice if you could.

>[..]
> Did you read the next bit where I pointed out that I use an
> editor that *doesn't* support tags, and even there I don't
> regard looking things up as a great burden?

  No, I must have accidentally skipped that bit.

>>  That's fascinating.
>
> That's a curious response to the demolition of your argument.

  I'm also a weird guy.

>>  because real code (here defined as written by professional
>>  programmers (i.e. people that program from 9 to 5) as opposed to CS
>>  professors) looks like this;
>>
>> bla(FooBlaBaxBar, FooFooBlaBaxBar, LaDiDaBaxBar, FooFooBlaBazBar,
>>    BlaBlaaBarBar, FooFooBlaBurpBar) ->
>>  when is_integer(FooFooBlaBaxBar), is_atom(FooFooBlaBazBar) ->
>>
>
> Hmm.  Code that looked like that would not get through syntax
> checking.

  Oops.

>  But since you are making a claim about "real code",
> why not *display* some real code, and let's see what we can do
> with it.

  I am no longer working at a place where people write code like that.

> 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. And
  even if they did they wouldn't listen to you, or anyone else trying
  to teach them anything. And they don't really care about making the
  code readable, because they won't read it. And the phrase "saving
  themselves work" doesn't make any sense because they work 9 to 5 no
  matter what.

  Real Programmers would of course not use Erlang in the first place.

>[...]
> 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.

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

  mats