Trouble with Erlang's lenient comparisons - Erlang Programming

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion Trouble with Erlang's lenient comparisons
Received-SPF: pass (google.com: domain of erlang-questions-boun...@erlang.org designates 192.121.151.104 as permitted sender) client-ip=192.121.151.104;
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
 h=mime-version:in-reply-to:references:date:message-id:subject:from:to
 :cc:content-type;
 b=YZ9JWephGShxpdmNzjw556+E3lrZwRhy392AFfFOnMAhKZIr3qQrUbXIEkzwUpQhPF
 KVVSGXP7zYpCOEEw+FfBMKEiUFLeJ6Ft5cPl32q4mxNXFroGyNwobixtVp0ApzXWOx9H
 AovQmD0kLTzKMGGUk8lR7kDCFYk3kHAvFS2GQ=
MIME-Version: 1.0
In-Reply-To: <BANLkTikTiCNGpJ98DmpXYxnV4WveQba...@mail.gmail.com>
References: <8c056228-a280-41e9-a6b0-20dd10f4b...@gu8g2000vbb.googlegroups.com>
 <BANLkTi=f4nabsPgEqSV=CN3VhJMnYAB...@mail.gmail.com>
 <4DA57CB6.7030...@cs.ntua.gr>
 <BANLkTikTiCNGpJ98DmpXYxnV4WveQba...@mail.gmail.com>
Date: Wed, 13 Apr 2011 13:26:58 +0200
Message-ID: <BANLkTikJn_LrTdQaFSdx3dLqBYUumNU...@mail.gmail.com>
From: Torben Hoffmann <torben.leh...@gmail.com>
To: =?ISO-8859-1?Q?H=E5kan_Mattsson?= <h...@tail-f.com>
Cc: erlang-questions <erlang-questi...@erlang.org>
Subject: Re: [erlang-questions] Trouble with Erlang's lenient comparisons
Precedence: list
Content-Type: multipart/mixed; boundary="===============4768710208294262114=="
Errors-To: erlang-questions-boun...@erlang.org
Sender: erlang-questions-boun...@erlang.org

--===============4768710208294262114==
Content-Type: multipart/alternative; boundary=0015176f1bd036811b04a0cb162c

--0015176f1bd036811b04a0cb162c
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

From a practical stand point I agree with Kostis.

When we started doing Erlang we used a lot of is_record/2 guards - that
generally makes the code a lot harder to understand, so we dropped that as
we threw away our imperative inheritance.

And the minute you need to take a parameter out of the record it will be
done with the pattern matching anyway, which makes it easier to make change=
s
in the code.

One learning here: try to do the pattern matching on fields only in the
cases where it is used to pick between different function clauses. It makes
it easier to figure out what is controlling the flow of execution and what
is merely taken out of the parameters to be used as input elsewhere.  We ha=
d
a lot of functions that pattern matched a lot of fields in a record, but
only one of the fields were used to control the flow of execution. It was
more clear to do a R#rec.field1 in the function code for the other fields.
But it is a matter of style, of course...

Cheers,
Torben

2011/4/13 H=E5kan Mattsson <h...@tail-f.com>

> When you discourage one way of writing code and claim that another way
> is better you ought to motivate why.
>
> /H=E5kan
>
> On Wed, Apr 13, 2011 at 12:36 PM, Kostis Sagonas <kos...@cs.ntua.gr>
> wrote:
> > Gordon Guthrie wrote:
> >>
> >> ...
> >>
> >> Also check for bad input to functions by using guards like:
> >>
> >> fun(A, B, C) when is_list(A), is_integer(B), is_record(C, recC) ->
> >
> > The following is a bit pedantic, but please do not offer use of the
> > is_record guard (esp. the one with arity two instead of three) as advic=
e
> to
> > newcomers.  I suggest that you try to forget about this guard's
> existence;
> > the only place where this guard is possibly needed is in or/orelse
> contexts.
> >
> > The above code is written better using pattern matching, as in:
> >
> >  fun(A, B, #recC{} =3D C) when is_list(A), is_integer(B) ->
> _______________________________________________
> erlang-questions mailing list
> erlang-questi...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>



--=20
http://www.linkedin.com/in/torbenhoffmann

--0015176f1bd036811b04a0cb162c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

From a practical stand point I agree with Kostis.<br><br>When we started do=
ing Erlang we used a lot of is_record/2 guards - that generally makes the c=
ode a lot harder to understand, so we dropped that as we threw away our imp=
erative inheritance.<br>
<br>And the minute you need to take a parameter out of the record it will b=
e done with the pattern matching anyway, which makes it easier to make chan=
ges in the code. <br><br>One learning here: try to do the pattern matching =
on fields only in the cases where it is used to pick between different func=
tion clauses. It makes it easier to figure out what is controlling the flow=
 of execution and what is merely taken out of the parameters to be used as =
input elsewhere.=A0 We had a lot of functions that pattern matched a lot of=
 fields in a record, but only one of the fields were used to control the fl=
ow of execution. It was more clear to do a R#rec.field1 in the function cod=
e for the other fields. But it is a matter of style, of course...<br>
<br>Cheers,<br>Torben<br><br><div class=3D"gmail_quote">2011/4/13 H=E5kan M=
attsson <span dir=3D"ltr">&lt;<a href=3D"mailto:h...@tail-f.com">h...@tail-f.co=
m</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
When you discourage one way of writing code and claim that another way<br>
is better you ought to motivate why.<br>
<font color=3D"#888888"><br>
/H=E5kan<br>
</font><div class=3D"im"><br>
On Wed, Apr 13, 2011 at 12:36 PM, Kostis Sagonas &lt;<a href=3D"mailto:kost=
i...@cs.ntua.gr">kos...@cs.ntua.gr</a>&gt; wrote:<br>
&gt; Gordon Guthrie wrote:<br>
&gt;&gt;<br>
&gt;&gt; ...<br>
&gt;&gt;<br>
&gt;&gt; Also check for bad input to functions by using guards like:<br>
&gt;&gt;<br>
&gt;&gt; fun(A, B, C) when is_list(A), is_integer(B), is_record(C, recC) -&=
gt;<br>
&gt;<br>
&gt; The following is a bit pedantic, but please do not offer use of the<br=
>
&gt; is_record guard (esp. the one with arity two instead of three) as advi=
ce to<br>
&gt; newcomers. =A0I suggest that you try to forget about this guard&#39;s =
existence;<br>
&gt; the only place where this guard is possibly needed is in or/orelse con=
texts.<br>
&gt;<br>
&gt; The above code is written better using pattern matching, as in:<br>
&gt;<br>
&gt; =A0fun(A, B, #recC{} =3D C) when is_list(A), is_integer(B) -&gt;<br>
</div><div><div></div><div class=3D"h5">___________________________________=
____________<br>
erlang-questions mailing list<br>
<a href=3D"mailto:erlang-questi...@erlang.org">erlang-questi...@erlang.org<=
/a><br>
<a href=3D"http://erlang.org/mailman/listinfo/erlang-questions" target=3D"_=
blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br><a href=3D"=
http://www.linkedin.com/in/torbenhoffmann">http://www.linkedin.com/in/torbe=
nhoffmann</a><br>

--0015176f1bd036811b04a0cb162c--

--===============4768710208294262114==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
erlang-questions mailing list
erlang-questi...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

--===============4768710208294262114==--
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
