[erlang-questions] Breaking out of a foldl

Mazen Harake <>
Mon Jun 1 13:08:34 CEST 2009


Yes smoother. Imagine the code bloat if you want to add a try catch 
around every other lists:x/y function... Absolutely smoother and nicer 
code. I use throw all the time for exactly the situation as you describe 
but on a higher level namely on component level. Now obviously someone 
is going to suggest to wrap a fold_until loop in a try catch and make a 
function out of it... well voila (or how ever that is spelt) your back 
to what I suggested, because wrapping it makes it smooooother. Another 
very obvious benefit is traceability and that it will be implemnted the 
same way across so that it will be well tested and safe. I'm sure there 
are many more...

So on the argument of smoother; Yes, it is...
In terms of it being a hack; Matter of definition I guess... for the 
reasons mentioned above I wouldn't recommend using try-catch for solving 
this problem

this leads me to the next question...

about the documentation... well there are more highlevel problems with 
the documentation. It seems you think that "bloating" the documentation 
is a bad thing for beginners, well I would rather say that the way the 
documentation is structures is the real problem. E.g. the fact there is 
no index in the beginning of each module where one can quickly get an 
overview of the functions. Then there are things like; I have to use 
google to search it (what??? THAT if something is unsmooth), I have to 
"know" what I'm looking for E.g. what is the difference between filelib, 
file, and filename (I'm sure it seems very obvious to us who have used 
it alot but not to beginners since that is what we are discussing).

If you are concerned about beginners (specially beginners coming from OO 
languages) you should be more worried about ridiculous things like 
parameterised modules which makes beginners _really_ confused... (Is it 
an object or not?? specially with the new construct)

With that being said I do agree with you that the set of the standard 
library should be small... but that doesn't mean that just because we 
want it small we don't include things that _make_sense_

/Mazen

Joe Armstrong wrote:
> On Sat, May 30, 2009 at 6:19 PM, Mazen Harake
> <> wrote:
>   
>> Because it is a hack?
>>
>> a "fold_until" would be much smoother.
>>     
>
> Uuugh - smoothness?????????????
>
> Why have two functions when one (the existing foldl) is perfectly adequate?
>
> The use of throw to abnormally terminate a recursion is not a hack.
> That is what
> catch-throw was designed to do. exit/1 is for raising errors, throw/1 is for
> abrupt termination of a computation.
>
>   
>> Consider this +1 to the set of people that wants this function in the lists
>> module :)
>>     
>
> Wirth (the blessed) said something like (paraphrased) every time we
> add something
> to a language we should ask *what can we remove*. If we just add stuff
> to languages
> (or libraries) - without removing stuff, we add additional complexity
> so we violate
> the principle of being as simple as possible.
>
> I am often horrified by libraries that offer dozens of different ways
> to do essentially the
> same thing - this makes the documentation almost unreadable (since it is unclear
> which the kernel methods are) and makes learning very difficult.
>
> Libraries should provide a small set of primitive parts which can be
> glued together
> to solve a large number of problems. If the set of parts is large then
> learning the library will be very difficult. If you don't know all the
> functions in a library then
> programming using the library will be painfully slow since you will
> have to google
> your way through large volumes of documentation.
>
> If you really really want fold_until then I suggest you make your own
> personal library
> (mylib.erl) where you put fold_until (and every other additional
> function that you think
> is missing from the standard libraries) - then one day when you are
> satisfied that
> your library has proved useful you can publish it.
>
> Exactly what should be in the standard libraries is an extremely
> difficult problem-
> I think they should contain small sets of orthogonal functions and err
> on the side
> of generality. If two function do more of less the same thing one of
> them should be removed.
>
> /Joe
>
>
>
>   
>> /M
>>
>> David Mercer wrote:
>>     
>>> Why not use throw and catch?  E.g.:
>>>
>>>  1> SumOr10 = fun(X, Y) when X + Y >= 10 -> throw(10); (X, Y) -> X + Y
>>> end.
>>>  #Fun<erl_eval.12.113037538>
>>>  2> catch lists:foldl(SumOr10, 0, [1,2,3]).
>>>  6
>>>  3> catch lists:foldl(SumOr10, 0, [1,2,3,4]).
>>>  10
>>>  4> catch lists:foldl(SumOr10, 0, [1,2,3,4,5]).
>>>  10
>>>
>>>
>>>       
>>>> -----Original Message-----
>>>> From:  [mailto:] On
>>>> Behalf Of Juan Jose Comellas
>>>> Sent: Friday, May 29, 2009 11:16 AM
>>>> To: Erlang Questions
>>>> Subject: [erlang-questions] Breaking out of a foldl
>>>>
>>>> Several times I've come across the need of a variant of foldl/foldr where
>>>> I
>>>> can break out of the iteration before going over allthe elements of a
>>>> list.
>>>> Has anybody thought of adding a function like the one below to the lists
>>>> module?
>>>>
>>>> bfoldl(Fun, Acc0, [Head | Tail]) ->
>>>>    case Fun(Head, Acc0) of
>>>>        {ok, Acc} ->
>>>>            bfoldl(Fun, Acc, Tail);
>>>>        {break, _Acc} = Result ->
>>>>            Result;
>>>>        break ->
>>>>            {break, Acc0}
>>>>    end;
>>>> bfoldl(_Fun, Acc0, []) ->
>>>>    {ok, Acc0}.
>>>>
>>>> Where a function can return {ok, Acc} to continue iterating and break /
>>>> {break, Acc} to interrupt it.
>>>>
>>>>         
>>> ________________________________________________________________
>>> erlang-questions mailing list. See http://www.erlang.org/faq.html
>>> erlang-questions (at) erlang.org
>>>
>>>
>>>       
>> ________________________________________________________________
>> erlang-questions mailing list. See http://www.erlang.org/faq.html
>> erlang-questions (at) erlang.org
>>
>>
>>     



More information about the erlang-questions mailing list