[erlang-questions] erlang sucks
Thu Mar 13 13:30:41 CET 2008
> Concerning 'if', may I remind readers that the 'cond' proposal (not
> has been around for quite a while, and except for using 'cond' rather
> than 'if' as the keyword, completely answers the claimed need for an if
> with user-defined functions callable in the guards.
Claimed need? Predicate functions are absolutely necessary in handling dispatch decisions for any sort of system whose message vocabulary is upgraded over time, in my experience. Having to put the explicit matching specification any place where a message or data structure is handled (even for simple dispatch pass-through which doesn't do anything with the contents) instead of deferring to a predicate is a horrible violation of DRY, and requires error-prone code hunting if it ever changes shape. Also, the ability to handle an entire category of messages via predicate, as opposed to matching each individual shape in its own clause, is substantial.
Of course, one work-around to the lack of functions in guards is to prepend all functions you'd use before the case/receive and bind their results in variables. That works, but again trashes your code organization, especially when your main receive or case dispatch gets to be fairly large; is again a violation of DRY putting all the gory message details into something that doesn't use them; and is horribly sub-optimal since everything is called all the time instead of only enough to get the result that's needed.
> What happens if those user defined functions exchange messages with the
> rest of the world is not something I want to think about...
If you're so worried about being coddled by the language, then we really need a notion similar to C++ "constness". Track and propagate which functions are pure functional, and toss compile-time, module-load time, or runtime errors if you choose to do so. I'd much rather have user-defined guard functions and have it upon myself to use them properly, than to throw out the baby with the bathwater just because it could possibly be misused.
Yeah, I'm a little irate about the guard issue, simply because it seems it's clung to purely because of stick-in-the-mud attitude. Yes, I know that guard BIFs compile into BEAM directly and have their own optimization strategy, but function calls are still BEAM code you can generate. I don't care if it's a bit slower. We use code generation from spec DSLs for all event types and now full protocol specifications, so the ability to defer "is this a Hello message?" decisions to external generated functions is a basic requirement. Right now, we have to try to hack it into ?IS_HELLO style macros which expand to only guard BIFs where it can fit and mess with .hrl files. If you say that that's a decent solution, I might have more irate words to dispense. ;)
Shed those extra pounds with MSN and The Biggest Loser!
More information about the erlang-questions