[erlang-questions] My biggest beef with Erlang
Tue Nov 27 13:36:24 CET 2007
> 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!
More information about the erlang-questions