erlang sucks

[Mats Cronqvist-3]

Sean Hinde wrote:
>
> On 11 Mar 2008, at 12:47, Mats Cronqvist wrote:
>
>>
>> * 'if' is  completely worthless, and should ideally be obsoleted.
>
> No, no no! I like 'if' It allows some neat constructs that are
> horrible with case.

  i was afraid no one was going to bite... still, I'd like an example or 2.

  mats


[mats_cronqvist.vcf]

---

begin:vcard
fn:Mats Cronqvist
n:Cronqvist;Mats
org:Kreditor Europe AB
email;internet:mats.cronqvist@...
title:Senior Developer
x-mozilla-html:FALSE
version:2.1
end:vcard

---

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

[Sean Hinde]

On 11 Mar 2008, at 19:26, Mats Cronqvist wrote:

> Sean Hinde wrote:
>>
>> On 11 Mar 2008, at 12:47, Mats Cronqvist wrote:
>>
>>>
>>> * 'if' is  completely worthless, and should ideally be obsoleted.
>>
>> No, no no! I like 'if' It allows some neat constructs that are  
>> horrible with case.
>
> i was afraid no one was going to bite... still, I'd like an example  
> or 2.

I'm thinking of things like:

case X of
        _ when X == abc; X == xyz ->
                do_abc_or_xyz();
         _ when X == '123', X == '456' ->
                do_123456()
        '123' ->
                do_123_only();
         fred ->
                 do_fred()
end

vs

if
        X == abc;
        X == xyz ->
                do_abc_or_xyz();
         X == '123',
        X == '456' ->
                do_123456();
        X == '123' ->
                do_123_only();
         X == fred ->
                 do_fred()
end

I don't much like the _ when business.

'if' is also useful when you want to branch on a bunch of unrelated  
boolean variables in various combinations:

case {X,Y,Z} of
        {true, false, _} ->
                do_a();
         {false, _, true} ->
                do_b();
        _ ->
                do_c()
end

vs

if
        X and not Y ->
             do_a;
        not X and Z ->
             do_b;
        true ->
             do_c
     end.

I find the second more clearly states the intent. You also don't have  
to remember the positions in the tuple to parse the code (though you  
do need to know that 'not' is stickier* than 'and')

Sean

* IANACS

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

[Ulf Wiger (TN/EAB)]

attila.rajmund.nohl@... skrev:

>
> There's one more thing that sometimes drive me nuts - due to the lack of
> decent 'if' statement, new functions are written instead of branches of
> a conditional statement. So I see a lot of code like this:
> do_something(X, Y) ->
>      really_do_something(X, Y).
>
> really_do_something(a, Y) ->
>      really_really_do_something(a, Y);
> ...
>
> really_really_do_something(a, b) ->
>      ... % could be a one liner
>
> The problem is that the really_really_do_something is way to long to
> type for people whose editor can't complete function names, so they'll
> write rrds instead - which is very non-intuitive. I've just checked and
> our code contains more than 150 functions with 3 character name, more
> than 50 functions with 2 character name and more than 150 functions with
> 4 character name. Some of these names actually make sense (e.g. get,
> set), but most of them do not - and I don't like function names that do
> not make sense. I haven't seen this practice in C++ or Java projects.

One very good reason for doing this(*) is that Erlang has excellent
trace facilities for function calls, but no ability to trace on
branching. I tend to agree that it often leads to less readable
code, but I don't agree that it's because of 'if' - at least not
in the cases where I've observed it in our code.

(*) this = using many small functions - not using illegible function
     names, which is just silly.

BR,
Ulf W
_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

[Richard O'Keefe]

On 11 Mar 2008, at 9:11 pm, Ulf Wiger wrote:
> Just like someone saying "kill two birds with one stone" most likely  
> doesn't mean it literally, I would wager that mr ROK did not  
> literally refer to Damien as a whining child - not least because he  
> is not literally offering a lollipop.


For what it's worth, it was an indirect reference to
Alan Perlis's epigram number 93:

        When someone says "I want a programming language in which I need
        only say what I wish done," give him a lollipop.

(See SIGPLAN Notices Vol. 17, No. 9, September 1982, pages 7-13.)
Epigram 73 is also relevant:

        It is not a language's weaknesses but its strengths that control
        the gradient of its change: Alas, a language never escapes its
        embryonic sac.

Epigram 93 got cross-linked with the fact that I *have* children who  
*do*
whine sometimes (well, one of them has experienced pretty much  
constant pain
for over a year and the hospital are having no luck diagnosing it; she  
can
bear it but it's no fun) and I *have* found it rational to offer a  
lollipop
from time to time (distraction is an approved method of coping with  
pain).
Some times there are other things you have to do, and there isn't any  
point
in arguing any more.

Take strings.  3 decades of computing have convinced me that in any  
and every
language STRINGS ARE WRONG.  Perl is the perfect example of how easy a
language can make it to write the wrong program (a program that does the
wrong thing, and does it badly).  I keep a book on my shelves to show  
to Perl
fans:  it's a book explaining in all earnest how to do some useful  
things in
Perl, and every single program in it has at least one fundamental flaw  
that
means it will mostly work most of the time, but break when you need it  
most.
One of the reasons I found C to be a vastly better language for text  
processing
than PL/I (yes, I'm old enough to have been a PL/I programmer) was  
that C did
NOT have a built in string data type.  One of the reasons that my C  
code can
still make student C++ code look like a sick snail is that C does not  
have a
built in string data type, and C++ these days does.  As for Java,  
let's not go
there.

I suspect that there are two things that influence my views which many  
others
do not share.  First, a taste for minimalism.  In many respects Erlang  
is a
minimalist language, in contrast to C++, which is a maximalist  
language (except
where it might be useful; the arguments against nested functions that  
made
sense for classic C are absurd in the context of C++).  Second,  
experience with
several declarative languages and familiarity with the "trees are  
trivial" way
of thinking that goes with that.  I have been shocked at how hard our
Java-trained students find trees to be; it's a safe bet that someone  
with a
C++ or Java or Perl or Python or Ruby background not only isn't going  
to think
of an alternative to strings for representing text, they aren't going  
to find it
imaginable that there might _be_ an alternative or that it might be  
desirable.

One particular experience sticks with me.  Before learning Prolog, I  
learned
Interlisp.  I was impressed by the Interlisp pattern-match compiler.  
Boy,
that was cool.  I thought.  When I met Prolog, I said to myself: "I  
would like
to have something like the Interlisp pattern-match compiler for  
Prolog.  What
I'll do is work through the Lisp pattern constructs and see how they  
can be
translated to Prolog, and then I'll write a compiler, using  
term_expansion/2."
But by the time I had finished seeing how to convert an Interlisp  
pattern to
Prolog, I didn't want Interlisp patterns any more.  That was for two  
reasons.
The first was that I could now write whatever Interlisp pattern I wanted
*directly* in Prolog, and it looked rather better.  The second was  
that I
realised that I should usually be using trees, not lists, so that I  
didn't
*have* to do complicated pattern matching.

So when people go on and on about wanting strings in Erlang, I find  
myself
wanting to shout THINK! MEASURE! IMAGINE!  Or "if you want Perl, you  
know
where to find it".  But there comes a point where you realise that  
that is
no longer rational.

The fact that we now have to deal with Unicode, which is much more
complicated than most programmers realise, means that a string data type
would *now* do more than soothe people crying for the old familiar ways
of doing things.  It really could make it easier for people to write
correct Erlang programs, by packaging up all the things that Unicode  
makes
tricky.  It *is* in the spirit of Erlang/OTP to provide support for
something tricky useful in communication, and binaries (which are  
logically
redundant, given tuples and integers) show that it's in the spirit of  
Erlang
to provide such support even at the expense of minimalism.


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

[Lennart Öhman-2]

I am compelled to "help" Sean. Further, I feel there is a difference
between to pattern-match a branch decision, and to do logical tests.

Example of perfectly legal but in my opinion ugly code (where 'if' or
using guards in a function-head of a help function is the correct
solution):

case X of
        X when X>10 ->

:-)

Lennart

---------------------------------------------------------------------------
Lennart Öhman                   phone   : [phone]
Sjöland & Thyselius Telecom AB  cellular: [phone]
Hälsingegatan 43, 10th floor    fax     : [phone]
SE-113 31 STOCKHOLM, SWEDEN     email   : lennart.ohman@...


-----Original Message-----
From: erlang-questions-bounces@... [mailto:erlang-questions-bounces@...] On Behalf Of Sean Hinde
Sent: den 11 mars 2008 20:18
To: Mats Cronqvist
Cc: Erlang mailing list
Subject: Re: [erlang-questions] erlang sucks


On 11 Mar 2008, at 12:47, Mats Cronqvist wrote:

>
> * 'if' is  completely worthless, and should ideally be obsoleted.

No, no no! I like 'if' It allows some neat constructs that are
horrible with case.

Counting 'if' and 'case' for one of the apps in our codebase gives
this result:

alex:src sean$ grep -v '^[[:space:]]*\($\|%\)' $(find . -name "*rl") |
grep " if " | wc -l
      345
alex:src sean$ grep -v '^[[:space:]]*\($\|%\)' $(find . -name "*rl") |
grep " case " | wc -l
     1052

~ one quarter of branching constructs are 'if'. Not at all
insignificant.

Sean

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

[Mats Cronqvist-3]

Sean Hinde wrote:

>
> On 11 Mar 2008, at 19:26, Mats Cronqvist wrote:
>
>> Sean Hinde wrote:
>>>
>>> On 11 Mar 2008, at 12:47, Mats Cronqvist wrote:
>>>
>>>>
>>>> * 'if' is  completely worthless, and should ideally be obsoleted.
>>>
>>> No, no no! I like 'if' It allows some neat constructs that are
>>> horrible with case.
>>
>> i was afraid no one was going to bite... still, I'd like an example
>> or 2.
>
> I'm thinking of things like:
>
> case X of
>     _ when X == abc; X == xyz ->
>         do_abc_or_xyz();
>         _ when X == '123', X == '456' ->
>         do_123456()
>     '123' ->
>         do_123_only();
>         fred ->
>                 do_fred()
> end
>
> vs
>
> if
>     X == abc;
>     X == xyz ->
>         do_abc_or_xyz();
>         X == '123',
>     X == '456' ->
>         do_123456();
>     X == '123' ->
>         do_123_only();
>         X == fred ->
>                 do_fred()
> end
>
> I don't much like the _ when business.

  of course, a less (more?) contrived example would be this;

  case is_imaginary(Friend) of
    true -> sad(self());
    false-> sound(self())
  end.

 vs.

 FriendIsImaginary = is_imaginary(Friend),
 if
   not FriendIsImaginary -> sad(self());
   true -> sound(self())
 end.

  where the second one makes my head spin. the point is that you can't
ignore the fact that you have to bind X, Y and Z in the 'if' example.

> 'if' is also useful when you want to branch on a bunch of unrelated
> boolean variables in various combinations:
>
> case {X,Y,Z} of
>     {true, false, _} ->
>         do_a();
>         {false, _, true} ->
>         do_b();
>     _ ->
>         do_c()
> end
>
> vs
>
> if
>     X and not Y ->
>             do_a;
>     not X and Z ->
>             do_b;
>     true ->
>             do_c
>     end.

  same here; when you take into account that you have to bind X, Y and Z

in the second example, but not in the first, the 'case' version comes
out ahead. objectively :>

  i remain convinced that 'if' is worthless and does nothing but add to
the bloat.

  mats

[mats_cronqvist.vcf]

---

begin:vcard
fn:Mats Cronqvist
n:Cronqvist;Mats
org:Kreditor Europe AB
email;internet:mats.cronqvist@...
title:Senior Developer
x-mozilla-html:FALSE
version:2.1
end:vcard

---

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

[Sean Hinde]

On 11 Mar 2008, at 22:11, Mats Cronqvist wrote:

> Sean Hinde wrote:
>>
>>
>> I don't much like the _ when business.
>
> of course, a less (more?) contrived example would be this;
>
> case is_imaginary(Friend) of
>   true -> sad(self());
>   false-> sound(self())
> end.
>
> vs.
>
> FriendIsImaginary = is_imaginary(Friend),
> if
>  not FriendIsImaginary -> sad(self());
>  true -> sound(self())
> end.
>
> where the second one makes my head spin. the point is that you can't  
> ignore the fact that you have to bind X, Y and Z in the 'if' example.

I agree your second version is ugly. That is why I idid not write my  
usage of 'if' in that way ;-)

OTOH in our shop we do have one or two horrible sections of code  
following your convention. In one place we have around 10 variables  
made boolean then scattered throughout a huge if with many clauses of  
complex boolean logic - head spinning indeed! Although it's not that  
obvious how to deal with it in a much better way. We could carefully  
pick it all apart, looking for state space reductions and building  
complex hiearchies of smaller functions, but that is a lot of work for  
perhaps little real gain...

>
>
>> 'if' is also useful when you want to branch on a bunch of unrelated  
>> boolean variables in various combinations:
>>
>> case {X,Y,Z} of
>>    {true, false, _} ->
>>        do_a();
>>        {false, _, true} ->
>>        do_b();
>>    _ ->
>>        do_c()
>> end
>>
>> vs
>>
>> if
>>    X and not Y ->
>>            do_a;
>>    not X and Z ->
>>            do_b;
>>    true ->
>>            do_c
>>    end.
> same here; when you take into account that you have to bind X, Y and  
> Z in the second example, but not in the first, the 'case' version  
> comes out ahead. objectively :>

Why, as the reader of the code, should I care that Z does not have to  
be bound. As the reader of the code I can divine the intention much  
more clearly with the second one, therefore it is better.

> i remain convinced that 'if' is worthless and does nothing but add  
> to the bloat.

1/4 of our code says you are wrong!

Sean

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

[attila.rajmund.nohl]

On Tue, 11 Mar 2008, Ulf Wiger (TN/EAB) wrote:

> attila.rajmund.nohl@... skrev:
>>
>> There's one more thing that sometimes drive me nuts - due to the lack of
>> decent 'if' statement, new functions are written instead of branches of
>> a conditional statement. So I see a lot of code like this:
>> do_something(X, Y) ->
>>      really_do_something(X, Y).
>>
>> really_do_something(a, Y) ->
>>      really_really_do_something(a, Y);
>> ...
>>
>> really_really_do_something(a, b) ->
>>      ... % could be a one liner
>>
>> The problem is that the really_really_do_something is way to long to
>> type for people whose editor can't complete function names, so they'll
>> write rrds instead - which is very non-intuitive. I've just checked and
>> our code contains more than 150 functions with 3 character name, more
>> than 50 functions with 2 character name and more than 150 functions with
>> 4 character name. Some of these names actually make sense (e.g. get,
>> set), but most of them do not - and I don't like function names that do
>> not make sense. I haven't seen this practice in C++ or Java projects.
>
> One very good reason for doing this(*) is that Erlang has excellent
> trace facilities for function calls, but no ability to trace on
> branching.

Yes, erlang has excellent trace facilities, it shows me that the 'rfmm'
function was called - unfortunately it doesn't show that which of the 10
rfmm functions was called. OK, I could figure out from the argument list
(also in the trace), but when the argument list is 100 lines long (you
have to pass the whole damn state as a parameter!), I just don't find it
that useful. Actually it's faster to insert some io:format calls into
the code and check the output.

> I tend to agree that it often leads to less readable
> code, but I don't agree that it's because of 'if' - at least not
> in the cases where I've observed it in our code.
>
> (*) this = using many small functions - not using illegible function
>    names, which is just silly.

I agree that using small functions is a good practice. However, many one
liner function just makes following the code flow harder, because in the
end the code is longer. One pattern I often see is:

some_function(X, Y, Z) ->
     rc(handle_some_function(X, Y, Z)).

rc(ok) ->
     ok;

rc(error1) ->
     handle_error1();

rc(error2) ->
     handle_error2().

I think this is just bloat, it's a lot more elegant even in pesudo-C:

some_function(X, Y, Z) {
     rc=handle_some_function(X, Y, Z);
     if (error1==rc) {
         handle_error1();
     }
     else if (error2==rc) {
         handle_error2();
     }
}

It's shorter by only 2 lines, still, my eyes don't have to jump around
that much when I follow the code. I guess this could be done in erlang
with if's, but the crusaders against if's have reached our design rule
document :-)
  Bye,NAR
--
NOHL Attila Rajmund,  Research Fellow
Ericsson R&D, Hungary, IP Services      Phone: [phone]
H-1037 Budapest, Laborc u. 1.           Fax:   [phone]
Email: Attila.Rajmund.Nohl@...
_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

[Sean Hinde]

On 11 Mar 2008, at 22:36, Nohl Attila Rajmund wrote:

> On Tue, 11 Mar 2008, Ulf Wiger (TN/EAB) wrote:
>
>> attila.rajmund.nohl@... skrev:
>>>
>>>
>
> I agree that using small functions is a good practice. However, many  
> one
> liner function just makes following the code flow harder, because in  
> the
> end the code is longer. One pattern I often see is:
>
> some_function(X, Y, Z) ->
>     rc(handle_some_function(X, Y, Z)).
>
> rc(ok) ->
>     ok;
>
> rc(error1) ->
>     handle_error1();
>
> rc(error2) ->
>     handle_error2().
>
> I think this is just bloat, it's a lot more elegant even in pesudo-C:
>
> some_function(X, Y, Z) {
>     rc=handle_some_function(X, Y, Z);
>     if (error1==rc) {
>         handle_error1();
>     }
>     else if (error2==rc) {
>         handle_error2();
>     }
> }
>
> It's shorter by only 2 lines, still, my eyes don't have to jump around
> that much when I follow the code. I guess this could be done in erlang
> with if's, but the crusaders against if's have reached our design rule
> document :-)

If rc is a common error handling function for many functions  
throughout the module then I'd say this was OK and serves it's purpose  
well.

The more normal Erlang way to write the equivalent of the C version  
would be simply:

some_function(X,Y,Z) ->
     case handle_some_function(X,Y,Z) of
         ok -> ok;
         error1 -> handle_error1();
         error2 -> handle_error2()
     end.

I'd argue that it is even more readable than the C version. And not an  
'if' in sight :-)

Sean



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

[Robert Virding]

On 11/03/2008, Mats Cronqvist <mats.cronqvist@...> wrote:

  i remain convinced that 'if' is worthless and does nothing but add to
the bloat.

It would actually be possible to extend 'if' to allow non-guard tests and user defined boolean functions in the test. Like in lisp. It would be almost backwards compatible in that existing code would behave the same, BUT there would be one fundamental difference for other tests. As the tests in 'if' are guard tests then type errors just equate to failure of the guard while an error in a non-guard test function (user or otherwise) would result in an error being generated for the whole 'if' and function. Catching errors in the test would probably be expensive (Björn?) and in some way break Erlang semantics in adding implicit 'try's.

But the resulting 'if' would definitely be more useful.

Robert

  mats

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

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

[Anders G S Svensson]

Attila.Rajmund.Nohl@... writes:

>
> On Tue, 11 Mar 2008, Ulf Wiger (TN/EAB) wrote:
>
> > attila.rajmund.nohl@... skrev:
> >
> > One very good reason for doing this(*) is that Erlang has excellent
> > trace facilities for function calls, but no ability to trace on
> > branching.
>
> Yes, erlang has excellent trace facilities, it shows me that the 'rfmm'
> function was called - unfortunately it doesn't show that which of the 10
> rfmm functions was called. OK, I could figure out from the argument list
> (also in the trace), but when the argument list is 100 lines long (you
> have to pass the whole damn state as a parameter!), I just don't find it
> that useful. Actually it's faster to insert some io:format calls into
> the code and check the output.

You might not think that when the code is at a customer site and
applying patches isn't something the customer (or the layers of
management between you and the customer) will let you do.

> > I tend to agree that it often leads to less readable
> > code, but I don't agree that it's because of 'if' - at least not
> > in the cases where I've observed it in our code.
> >
> > (*) this = using many small functions - not using illegible function
> >    names, which is just silly.
>
> I agree that using small functions is a good practice. However, many one
> liner function just makes following the code flow harder, because in the
> end the code is longer. One pattern I often see is:

This is just your opinion of course but consider your example below
and replace handle_error1/handle_error2 with calls to some popular OTP
function say. The advantage of the one-liners is that you can see what
code you've executed by tracing on rc/1 alone. Rewrite it as a case
and you might still be able to if the different branches of your case
return distinct values but if not then you have to trace on these
popular OTP functions as well, which may give you a lot more trace
than you bargained for for starters. Things can get a lot worse in
real code in which constructing appropriate trace to determine what's
going on can be a real chore.

If I had my way I'd remove the case statement along with the if
statement since their overuse can effectively negate the advantage
that the trace facilities provide.

Anders

>
> some_function(X, Y, Z) ->
>      rc(handle_some_function(X, Y, Z)).
>
> rc(ok) ->
>      ok;
>
> rc(error1) ->
>      handle_error1();
>
> rc(error2) ->
>      handle_error2().
>
> I think this is just bloat, it's a lot more elegant even in pesudo-C:
>
> some_function(X, Y, Z) {
>      rc=handle_some_function(X, Y, Z);
>      if (error1==rc) {
>          handle_error1();
>      }
>      else if (error2==rc) {
>          handle_error2();
>      }
> }
>
> It's shorter by only 2 lines, still, my eyes don't have to jump around
> that much when I follow the code. I guess this could be done in erlang
> with if's, but the crusaders against if's have reached our design rule
> document :-)
>   Bye,NAR
> --
> NOHL Attila Rajmund,  Research Fellow
> Ericsson R&D, Hungary, IP Services      Phone: [phone]
> H-1037 Budapest, Laborc u. 1.           Fax:   [phone]
> Email: Attila.Rajmund.Nohl@...

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

[Ulf Wiger (TN/EAB)]

Robert Virding skrev:

>
> It would actually be possible to extend 'if' to allow non-guard tests
> and user defined boolean functions in the test. Like in lisp. It would
> be almost backwards compatible in that existing code would behave the
> same, BUT there would be one fundamental difference for other tests. As
> the tests in 'if' are guard tests then type errors just equate to
> failure of the guard while an error in a non-guard test function (user
> or otherwise) would result in an error being generated for the whole
> 'if' and function. Catching errors in the test would probably be
> expensive (Björn?) and in some way break Erlang semantics in adding
> implicit 'try's.
>
> But the resulting 'if' would definitely be more useful.

If there's such a dire need for an if-like construct with
slightly different semantics than the existing 'if', let's
not break existing code by changing 'if', but rather adding
(bloat) another construct. Perhaps we should call it 'switch',
and make it almost like a C switch, but subtly different in
creative ways? (:

The 'if' statement is not high on my list of things that need
improving. It's actually quite ok, except it could perhaps have
been named differently, in order not to give people false
expectations.

BR,
Ulf W
_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

[Mats Cronqvist-3]

Ulf Wiger (TN/EAB) wrote:

> Robert Virding skrev:
>  
>> ...
>> But the resulting 'if' would definitely be more useful.
>>    
> ...
>
> The 'if' statement is not high on my list of things that need
> improving. It's actually quite ok, except it could perhaps have
> been named differently, in order not to give people false
> expectations.

 
  just to be clear; i don't think 'if ' should be improved.
  and i realize it cannot be removed either :<

  what i proposed was that it'd be obsoleted. in practice that would
mean that there'd
be a prominent document named "Obsolete features" or somesuch. That
document would list
old cruft; such as
* 'if'
* the three different 'and' (*)
* split_binary()
* the old type guards (integer() vs. is_integer())
* tuple funs
etc...

  mats

(*)
(case x of x when true,false ->ok; _-> nok end.
nok
case x of x when true and false ->ok; _-> nok end.
nok
case x of x when true andalso false ->ok; _-> nok end.
nok

[mats_cronqvist.vcf]

---

begin:vcard
fn:Mats Cronqvist
n:Cronqvist;Mats
org:Kreditor Europe AB
email;internet:mats.cronqvist@...
title:Senior Developer
x-mozilla-html:FALSE
version:2.1
end:vcard

---

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

[Thomas Lindgren]

--- Robert Virding <rvirding@...> wrote:

> On 11/03/2008, Mats Cronqvist
> <mats.cronqvist@...> wrote:
> >
> >
> >
> >   i remain convinced that 'if' is worthless and
> does nothing but add to
> > the bloat.
>
>
> It would actually be possible to extend 'if' to
> allow non-guard tests and
> user defined boolean functions in the test. Like in
> lisp.

We even have a keyword waiting for this: cond. On
consideration, I think I'd prefer instead generalizing
guards into deep guards (ie, at the very least,
user-defined calls available) everywhere.

An arbitrary call exiting in a guard would have to
convert to failure, just as guards work today. I'd
also suggest turning off side-effects while inside a
guard (even deep down in function calls), converting
attempted side-effects into exits.

(I guess the modest proposal above ought to be an EEP
too.)

Best,
Thomas




      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

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

[Hynek Vychodil]

2008/3/12 Mats Cronqvist <mats.cronqvist@...>:

Ulf Wiger (TN/EAB) wrote:

> Robert Virding skrev:
>
>> ...

>> But the resulting 'if' would definitely be more useful.
>>

> ...

>
> The 'if' statement is not high on my list of things that need
> improving. It's actually quite ok, except it could perhaps have
> been named differently, in order not to give people false
> expectations.

 just to be clear; i don't think 'if ' should be improved.
 and i realize it cannot be removed either :<

 what i proposed was that it'd be obsoleted. in practice that would
mean that there'd
be a prominent document named "Obsolete features" or somesuch. That
document would list
old cruft; such as
* 'if'
* the three different 'and' (*)
* split_binary()
* the old type guards (integer() vs. is_integer())
* tuple funs
etc...

 mats

(*)
(case x of x when true,false ->ok; _-> nok end.
nok
case x of x when true and false ->ok; _-> nok end.
nok
case x of x when true andalso false ->ok; _-> nok end.
nok

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

If you don't know reason, don't say there is not reason:

6> F1 = fun() -> ok =/= io:format("F1~n") end.
#Fun<erl_eval.20.62269157>
7> F2 = fun() -> ok =/= io:format("F2~n") end.
#Fun<erl_eval.20.62269157>
8> F1() and F2().
F1
F2
false
9> F1() andalso F2().
F1
false


--
--Hynek (Pichi) Vychodil
_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

[Mats Cronqvist-3]

Hynek Vychodil wrote:

>
>
> 2008/3/12 Mats Cronqvist <mats.cronqvist@...
> <mailto:mats.cronqvist@...>>:
>
>
>     * 'if'
>     * the three different 'and' (*)
>     * split_binary()
>     * the old type guards (integer() vs. is_integer())
>     * tuple funs
>     etc...
>
>      mats
>
>     (*)
>     (case x of x when true,false ->ok; _-> nok end.
>     nok
>     case x of x when true and false ->ok; _-> nok end.
>     nok
>     case x of x when true andalso false ->ok; _-> nok end.
>     nok
>
>     _______________________________________________
>     erlang-questions mailing list
>     erlang-questions@... <mailto:erlang-questions@...>
>     http://www.erlang.org/mailman/listinfo/erlang-questions
>
>
> If you don't know reason, don't say there is not reason:

  i am aware that the different kinds of 'and' are subtly incompatible.

that's the reason i think it's a problem...

  or are you saying there is a need for several 'and'? in that case i
disagree.

  mats


[mats_cronqvist.vcf]

---

begin:vcard
fn:Mats Cronqvist
n:Cronqvist;Mats
org:Kreditor Europe AB
email;internet:mats.cronqvist@...
title:Senior Developer
x-mozilla-html:FALSE
version:2.1
end:vcard

---

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

[Richard Kelsall]

Nohl Attila Rajmund wrote:
> Yes, erlang has excellent trace facilities, it shows me that the 'rfmm'
> function was called - unfortunately it doesn't show that which of the 10
> rfmm functions was called.

Breaking a small subject off the main thread. I haven't written much
Erlang yet so maybe I'm just missing something, but I get the impression
Erlang won't tell me the line number when something goes wrong. I feel
it would be useful to know this and very in keeping with the Erlang
approach of making bugs nice and visible. So my vote while we're all
requesting changes to Erlang :) is for more line number visibility.

On a related subject I've played around with the LINE macro to tag
my own logging/error messages with line numbers and the best I could
produce was something like this :

   -define(log(Line, Message, Var), log_message(?MODULE, Line, Message,
           ??Var, Var)).  % LINE macro always gives '1' if I put it here.

   log_message(Module, Line, Message, VarName, Var) ->
      io:format("log: {~p, ~p} ~s ~s = ~p~n", [Module, Line, Message,
                VarName, Var]).

and then in my code I can do things like

     ?log(?LINE, "Unexpected post", Other),

This works fine, but it would be nice to just write

     ?log("Unexpected post", Other),

and get the line number somehow. Can this be done?


Richard.

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

[Hynek Vychodil]

On Wed, Mar 12, 2008 at 3:02 PM, Mats Cronqvist <mats.cronqvist@...> wrote:

Hynek Vychodil wrote:
>
>
> 2008/3/12 Mats Cronqvist <mats.cronqvist@...

> <mailto:mats.cronqvist@...>>:

>
>
>     * 'if'
>     * the three different 'and' (*)
>     * split_binary()
>     * the old type guards (integer() vs. is_integer())
>     * tuple funs
>     etc...
>
>      mats
>
>     (*)
>     (case x of x when true,false ->ok; _-> nok end.
>     nok
>     case x of x when true and false ->ok; _-> nok end.
>     nok
>     case x of x when true andalso false ->ok; _-> nok end.
>     nok
>
>     _______________________________________________
>     erlang-questions mailing list

>     erlang-questions@... <mailto:erlang-questions@...>

>     http://www.erlang.org/mailman/listinfo/erlang-questions
>
>
> If you don't know reason, don't say there is not reason:

 i am aware that the different kinds of 'and' are subtly incompatible.
that's the reason i think it's a problem...

 or are you saying there is a need for several 'and'? in that case i
disagree.

Well, than say it to Joe :-)

'and' is and in mathematical manner
'andalso' is lazy and in programmers manner

I think there is no way to change it, because if you remove 'andalso' and use 'and' in programmers manner lazy behaviour, you will break some legacy code a vice versa. This change is impossible. You can be not agree with it. You can argue against it, but it is all what you can do with it.

 mats

--
--Hynek (Pichi) Vychodil
_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

[Mats Cronqvist-3]

Hynek Vychodil wrote:

>
>
> On Wed, Mar 12, 2008 at 3:02 PM, Mats Cronqvist
> <mats.cronqvist@... <mailto:mats.cronqvist@...>> wrote:
>
>       or are you saying there is a need for several 'and'? in that case i
>     disagree.
>
> ...
> I think there is no way to change it, because if you remove 'andalso'
> and use 'and' in programmers manner lazy behaviour, you will break
> some legacy code a vice versa. This change is impossible. You can be
> not agree with it. You can argue against it, but it is all what you
> can do with it.

  if you go back a few posts, you'll see that i try to make it very

clear that nothing will be removed (at least not for the next few years).
 
  mats

[mats_cronqvist.vcf]

---

begin:vcard
fn:Mats Cronqvist
n:Cronqvist;Mats
org:Kreditor Europe AB
email;internet:mats.cronqvist@...
title:Senior Developer
x-mozilla-html:FALSE
version:2.1
end:vcard

---

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

[Eider Oliveira]

I use this:

-define(d(Format, Args),
         io:format("~s" ++ Format,  
[string:left(lists:flatten(io_lib:format("~p~p(~p):", [self(),?
MODULE, ?LINE])), 35, $ ) | Args])).


On 12/03/2008, at 12:08, Richard Kelsall wrote:

> Nohl Attila Rajmund wrote:
>> Yes, erlang has excellent trace facilities, it shows me that the  
>> 'rfmm'
>> function was called - unfortunately it doesn't show that which of  
>> the 10
>> rfmm functions was called.
>
> Breaking a small subject off the main thread. I haven't written much
> Erlang yet so maybe I'm just missing something, but I get the  
> impression
> Erlang won't tell me the line number when something goes wrong. I feel
> it would be useful to know this and very in keeping with the Erlang
> approach of making bugs nice and visible. So my vote while we're all
> requesting changes to Erlang :) is for more line number visibility.
>
> On a related subject I've played around with the LINE macro to tag
> my own logging/error messages with line numbers and the best I could
> produce was something like this :
>
>   -define(log(Line, Message, Var), log_message(?MODULE, Line, Message,
>           ??Var, Var)).  % LINE macro always gives '1' if I put it  
> here.
>
>   log_message(Module, Line, Message, VarName, Var) ->
>      io:format("log: {~p, ~p} ~s ~s = ~p~n", [Module, Line, Message,
>                VarName, Var]).
>
> and then in my code I can do things like
>
>     ?log(?LINE, "Unexpected post", Other),
>
> This works fine, but it would be nice to just write
>
>     ?log("Unexpected post", Other),
>
> and get the line number somehow. Can this be done?
>
>
> Richard.
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@...
> http://www.erlang.org/mailman/listinfo/erlang-questions

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