principle of least surprise

Thomas Lindgren thomasl_erlang@REDACTED
Tue Nov 22 15:42:08 CET 2005

--- "Ulf Wiger (AL/EAB)" <ulf.wiger@REDACTED>

> Nick Linker wrote:
> >
> > Hm, what, in your opinion, about the possibility
> to be an 
> > arbitrary function (returning true or false, of
> course) in 
> > guards? Will it make the language better?
> The problem of that obviously is that normal erlang
> functions
> can contain side-effects, loops, and all sorts of
> scary stuff.

On consideration, I don't think this is a big problem.

First, I think the "shallow guard" restriction
inherited from concurrent logic programming is
unnecessary in Erlang's case. Erlang doesn't have the
same implementation problems, and it seems eminently
reasonable to turn side-effects into failure by
looking at the context when the side effect occurs.
("Am I being evaluated inside a guard?") Perhaps by
just setting and clearing/restoring a flag. I think
this has been proposed a number of times over the
years; I know I have. (My proposal obviously didn't
convince :-)

Second, pragmatically speaking, if the alternative to
using a guard is to write a case-statement, what have
we gained? The code is no clearer, the same issues
still turn up. Is it any better to write

"case (E1 andalso E2 andalso E3) of
  true -> ...;
  false -> ...

(and maybe that should be wrapped in a try or catch as
well to handle failure)

rather than "when E1, E2, E3 -> ...; ..."?

For these reasons, I think the introduction of deep
guards is well worth investigating. (I'm willing to be
convinced otherwise, of course.)

(I wouldn't mind deprecating and removing some
misfeatures in addition to that, of course.)


Yahoo! Mail - PC Magazine Editors' Choice 2005

More information about the erlang-questions mailing list