[erlang-questions] My biggest beef with Erlang

[Joe Armstrong]

As you say it's pretty easy to analyse a function for side effects -
we did this years ago. The problem
is rather that we want guards to be viewed as an extension of pattern
matching so we can guarantee
that we can produce efficient code for pattern matching.

Suppose we have a nice set of guards

     foo(...) when G1 -> ...
     foo(...) when G2 -> ...
     ...
     foo(...) when Gn -> ...

and we allow only a user defined guard (Ug) somewhere in the middle of
all of this

     foo(...) when G1 -> ...
     foo(...) when G2 -> ...
     ...
     foo(...) when Gn; Ug ->
     ...
     foo(...) when Gn -> ...

This would complete destroy all our well thought out pattern matching
optimisations that take place
when compiling foo.

The point of having a limited set of fixed guard tests is we can
analyse these at compile time and generate
an efficient matching tree.

If you want to extend the control structures with your own guards and
roll your own syntactic constructs use
funs and simulate monads or whatever - that's what funs are for.

/Joe Armstrong


On Nov 27, 2007 1:36 PM, David Holz <david_holz@REDACTED> wrote:
>
> From: rvirding@REDACTED
> > I actually defy anyone to come up with a safe, consistent and *understandable* definition of
> > guards which allow user defined functions. It would also be nice if they were relatively easy
> > to implement. Joe, remember our ideas with pipes?
>
> Hmm, how hard is it really to define?  It seems to me to be exactly like C++ const propagation.  There are a few things which can mutate state (process dict, message send/receive, ets et al, etc):
>
> - If a function calls built-in state mutators anywhere in its body, it's not pure functional.
> - If a function calls any other function that isn't pure functional, it's not pure functional.
> - If a function calls any M:F via variables instead of explicitly, tag it as not pure functional. (to make it easy to implement for an initial revision)
> - Only pure functional functions can be called in guards.
>
> The only challenging part is the dynamic code loading, which has similar issues to the M:F variable situation.  Inside a guard context, M:F call syntax would have to check the purity of the function it's calling, which can be cached between code loads.  This is really a linking issue, though, and could be theoretically designed not to have any per-call overhead for explicitly stated m:f's.  I'm not saying it's dirt simple to implement, but the idea of contagiously propagating "non-functionalness" shouldn't be difficult to define.
>
> I, however, would like to see a setting or switch somewhere to just remove the "is_guard_bif" checking completely, leaving it up to me to not do anything stupid, without inflicting any extra load doing runtime guard checks.  I think it should be straightforward to recompile the compiler myself with "is_guard_bif(_,_) -> true." but I haven't bothered with that yet.
>
> _________________________________________________________________
> Share life as it happens with the new Windows Live.Download today it's FREE!
> http://www.windowslive.com/share.html?ocid=TXT_TAGLM_Wave2_sharelife_112007
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>