[erlang-questions] Trouble with Erlang's lenient comparisons

JohnyTex ekeroth.christoffer@REDACTED
Wed Apr 13 15:42:41 CEST 2011

Thanks for the advice guys! I managed to get Dialyzer running and it
worked very nicely; it managed to spot some unreachable code right off
the bat :)

However, it doesn't seem to get the more insidious errors that arise
from comparing other types than was intended, i.e. accidentaly
comparing a string to an integer... but since it's completely valid
Erlang I guess it's not supposed to complain?

I will heed your advice and insert some type checking where
appropriate, thanks :)

The code is written in a very imperative style and I will try to
rewrite it to look more like Erlang as well, which I hope will solve a
lot of my problems.

Kind of off topic, but does anyone have experience with Haskell and
its type system? I keep hearing claims like "if it compiles, it
works!", and so on, which does sound quite nice... if it's true ;)

On 13 Apr, 13:26, Torben Hoffmann <torben.leh...@REDACTED> wrote:
> 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 changes
> 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 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 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åkan Mattsson <h...@REDACTED>
> > When you discourage one way of writing code and claim that another way
> > is better you ought to motivate why.
> > /Håkan
> > On Wed, Apr 13, 2011 at 12:36 PM, Kostis Sagonas <kos...@REDACTED>
> > 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 advice
> > 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{} = C) when is_list(A), is_integer(B) ->
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questi...@REDACTED
> >http://erlang.org/mailman/listinfo/erlang-questions
> --http://www.linkedin.com/in/torbenhoffmann
> _______________________________________________
> erlang-questions mailing list
> erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions

More information about the erlang-questions mailing list