[erlang-questions] My biggest beef with Erlang

David Holz david_holz@REDACTED
Tue Nov 27 13:36:24 CET 2007

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!

More information about the erlang-questions mailing list