[erlang-questions] Simple Erlang Recommendation (last returned value)

Hynek Vychodil <>
Sun Jul 27 21:26:57 CEST 2008


On Sun, Jul 27, 2008 at 9:09 PM, Hynek Vychodil <>wrote:

>
>
> On Sun, Jul 27, 2008 at 10:56 AM, <>wrote:
>
>> On Sat, 26 Jul 2008, Alain O'Dea wrote:
>>
>> > On 26-Jul-08, at 6:47 PM, James Hague wrote:
>> >
>> >>> Imagine this:
>> >>>
>> >>> X = tl(L),
>> >>> ... many messy lines ...
>> >>> *X = tl(X),
>> >>> ... another many lines ...
>> >>> *X = tl(X),
>> >>> ... another many almost unreadable messy lines ...
>> >>> sensitive_usage(X), % <--- buggy X value observed here
>> >>>
>> >>> And my question is, where Value of X came from? It goes from L, but
>> >>> how long
>> >>> it take and how many errors you can do when you will investigate?
>> >>
>> >> It's just as bad when there's code like this:
>> >>
>> >> T2 = something(T),
>> >> T3 = something(T2),
>> >> T4 = something(T3),
>> >> T5 = something(T4),
>> >> T6 = something(T5)
>> >>
>> >> You may laugh at that code, but it's hardly uncommon, even in code
>> >> written by experienced programmers.  It's very easy to accidentally
>> >> use T4 in a spot when you meant T3, or to have to renumber things and
>> >> make a mistake.
>> >>
>> >> Please note that I am not arguing for changes in Erlang.  I truly am
>> >> not.  But I can understand why this request comes up regularly.
>> >>
>> >> James
>> >
>> > Erlang should not introduce mutable variables because they make it
>> > easy to disguise a variety of code smells as clean code.
>> >
>> > Code like James' example is code that does not express its intentions
>> > clearly.
>>
>> I disagree. Code like this:
>> State1 = updateStateSomehow1(State, SomeVariable),
>> State2 = updateStateSomehow2(State1, SomeOtherVariable),
>> State3 = updateStateSomehow3(State2, SomeReallyOtherVariable),
>>
>> quite clearly expresses the intention: update the state.
>
>
> Well, if you want this, do it this way:
>
> NewStata = lists:foldl(
>    fun({F, A}, S) -> F(S, A) end,
>    State,
>       [
>          {updateStateSomehow1,SomeVariable},
>          {updateStateSomehow2, SomeOtherVariable},
>          {updateStateSomehow3, SomeReallyOtherVariable}
>    ]).
>
> Just refactor your code, don't break Language!
>

It should be
NewStata = lists:foldl(
   fun({F, A}, S) -> ?MODULE:F(S, A) end,
   State,
      [
         {updateStateSomehow1, SomeVariable},
         {updateStateSomehow2, SomeOtherVariable},
         {updateStateSomehow3, SomeReallyOtherVariable}
   ]).

or

NewStata = lists:foldl(
   fun({F, A}, S) -> F(S, A) end,
   State,
      [
         {fun updateStateSomehow1/2, SomeVariable},
          {fun updateStateSomehow2/2, SomeOtherVariable},
         {fun updateStateSomehow3/2, SomeReallyOtherVariable}
   ]).

or

NewStata = lists:foldl(
   fun({M, F, A}, S) -> F(S, A) end,
   State,
      [
         {someModule, updateStateSomehow1, SomeVariable},
          {otherModule, updateStateSomehow2, SomeOtherVariable},
         {yetAnotherModule, updateStateSomehow3, SomeReallyOtherVariable}
   ]).

or what ever you really wont.

In most cases, when your Erlang code looks ugly, you do ugly think or you
structure your code wrong way.


>
>
>>
>> [...]
>> > If you give semantic names to each transformation applied to the data,
>> > then the code will express its intentions clearly. When you express
>> > your intentions clearly you avoid a lot of bugs. Subsequent
>> > refactoring work is also made easier, especially when the original
>> > author is unavailable.
>>
>> The problem with detailed semantic names is that they tend to be long.
>> Given the ugliness of the erlang record syntax you'd soon end up with
>> experssions like this:
>> StateUpdatedWithSomeVariable#stateRecord.some_field
>>
>> instead of the intuitive
>> State.some_field
>>
>> which is actually readable and fits on the terminal nicely, unlike the
>> erlang variant.
>>
>>                                Bye,NAR
>> --
>> "Beware of bugs in the above code; I have only proved it correct, not
>>  tried it."
>> _______________________________________________
>> erlang-questions mailing list
>> 
>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>
>
>
>
> --
> --Hynek (Pichi) Vychodil
>



-- 
--Hynek (Pichi) Vychodil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080727/e0b1d4bd/attachment.html>


More information about the erlang-questions mailing list