[erlang-questions] My biggest beef with Erlang
Tue Nov 27 19:10:21 CET 2007
> 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.
I've looked at the generated Beam code for a few cases, and it does look pretty tight. I can't imagine, though, that the Ug in here
> foo(...) when G1 -> ...
> foo(...) when G2 -> ...
> foo(...) when Gn; Ug ->
> foo(...) when Gn -> ...
would eliminate all the optimizations that apply to G1...Gn-1. I would think that the optimizer could just consider the Gn; Ug clause as "already optimized", just like it would with a guard-bif clause that can't be optimized for other reasons, and continue cranking on the rest.
> 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.
Yes, but it's far more syntactically orthogonal (not to mention MUCH shorter) to just be able to put the calls into the guard clauses.
It's definitely an ease-of-human-use vs ease-of-computation tradeoff here, and when you want the productivity and clarity benefits of having it all in the guards regardless of it running a bit slower, it'd be nice to have that option. It's hard to maintain any sense of design encapsulation with deeply nested structures if you can't defer matching to user-defined predicate functions without jumping through extra hoops, especially when the code is young and structures change as the program grows.
Of course, another option is to use a parse transform to inline your user-defined fun bodies directly into the guard expressions, but that's pretty hackish.
Put your friends on the big screen with Windows Vista® + Windows Live™.
More information about the erlang-questions