[erlang-questions] Breaking out of a foldl

[David Mercer]

> 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).

But throw/1 is not used to throw exceptions: it is used to throw (quoting
from the documentation) "A non-local return from a function."  That seems to
fit the bill in this case.  That other languages make throwing expensive
enough to recommend that it only be used in exceptional circumstances is a
restriction on their implementations, not Erlang's.

> -----Original Message-----
> From: erlang-questions@REDACTED [mailto:erlang-questions@REDACTED] On
> Behalf Of Attila Rajmund Nohl
> Sent: Monday, June 01, 2009 1:44 PM
> To: erlang-questions@REDACTED
> Subject: [erlang-questions] Breaking out of a foldl
> 
> 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).
> 
> [...]
> > 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.
> 
> 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. This obviously means that the dbg module needs
> a function that simply turns on tracing on a function of a module.
> Yes, it could be done with dbg:tpl, but why shall I type every time
> [{'_',[],[{return_trace}]}] into the shell? Also the equivalent of
> lists:keyfind was probably implemented countless times in most Erlang
> projects.
> 
> I do think it's better to have often needed code in the standard
> library. First of all, it's standard, so every programmer should be
> familiar with it. On the other hand the "helper" functions in the
> various mylib libraries are probably not well known to anyone except
> the author. The above mentioned tracing modules had functions doing
> essentially the same, but each with a slightly different syntax which
> is quite annoying.
> 
> Using third party libraries (e.g. someone's released mylib) has other
> drawbacks. It might not be useable at all due to licensing. It's an
> other dependency that has to be followed (e.g. when a bugfix release
> comes out). It might not be maintained anymore. It doesn't have the
> same user base as the standard library, so it might have more bugs.
> From the management point of view it's better to work with the
> standard library and in-house code, without 3rd party libraries.
> 
> I think that the standard library should first and foremost make
> programming easier. For example, the JTable class in Java has 7
> constructors. A couple of them probably could be removed to get a more
> minimal code - but the removed code will popup in the applications
> many more times and probably with many more bugs.
> 
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org