Breaking out of a foldl
Tue Jun 2 09:56:44 CEST 2009
Attila Rajmund Nohl <attila.r.nohl@REDACTED> writes:
> 2009/6/1, Joe Armstrong <erlang@REDACTED>:
>> On Sat, May 30, 2009 at 6:19 PM, Mazen Harake
>> <mazen.harake@REDACTED> 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.
> Yeah, but it's syntax is somewhat misleading. People with
> Java/C++/Eiffel/etc. background would expect that exceptions should be
> used in exceptional situation, not instead of a return statement
> (which Erlang lacks).
Erlang might lack the keyword 'return', but it does have a non-local
return construct; 'throw'. Whether or not C++ have problems with
that seems quite off-topic here.
>> 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.
> I disagree. Every Erlang project I've seen had it's own tracing module
> built on top of dbg. They all had very similar functions that did
> nearly the same thing.
Perhaps we can agree that keeping the core libraries small, consistent
and intuitive is a very good thing (*).
Your complaints about dbg is, I think, a different issue; the
unwillingness of OTP to add even the most obvious of enhancements to
the stdlibs. E.g. the (thankfully no longer) missing string:join
function, the lack of which had been discussed for like 15 years
before it finally appeared.
(*) Unfortunately, the current libs fails on all of these; there's way
too much cruft (like lists:foldr), they're inconsistent (like string
sub_string/substr) and counter-intuitive ( try e.g. lists:seq(2,1)).
More information about the erlang-questions