Enhanced type guard syntax]
Thu Sep 18 17:09:21 CEST 2003
On Thu, 18 Sep 2003 16:16:12 +0200
"Vlad Dumitrescu" <vlad_dumitrescu@REDACTED> wrote:
> Joe wrote:
> > Adding guards like this violates one of my favorite
> > design
> > meta-principles: " If you add something to a language you have
> > to chuck
> > away "
> > What are we going to chuck away? Well not "when ->" ... Since
> > you can't
> > foo(X, Y) when X == 2*Y ->
> > in the new syntax
> > So you keep "when" - now there are TWO ways of saying things
> > foo(A/integer, B/integer)
> > or
> > foo(A, B) when is_integer(A), is_integer(B) ->
> > and people will write:
> > foo(A/integer, B) when is_integer(B) ->
> > ...
> > etc.
> Why not throw away the "when is_integer()" guards? Let type be only be
> specified using the new syntax, and let other kind of guards be
> specified as before. It seems to me it should work. What do you think?
I think you CAN throw "when" completely away IF you take this new syntax
proposal to its logical extreme.
foo(X, Y) when X == 2*Y
foo(X == 2 * Y)
This could also handle the other cases currently handled by "when" in a
much more readable fashion, viz:
foo(X > 3, Y > 3)
foo(1 < X < 10, is_integer(Y))
foo(X * Y > 100, X < Y)
As you can maybe see, the rules change - no longer is it an argument
list in the same way. The "," symbol takes on the meaning of "and", and
the order that variables are mentioned establishes their bindings (so
all the above examples would bind the first argument to X and the second
to Y, even though sometimes X is mentioned more than once, sometimes
there is no "," at all, etc.)
But this would completely obviate all need for "when" clauses, AFAICS.
What you would probably have to throw away would be easy
constant-matching - you can't have a function head like
foo(100, 200) ->
anymore, because it doesn't "mean" anything; you have to either say
foo(X == 100, Y == 200)
or write a REALLY clever (probably detrimentally so) compiler.
> Of course, this would break backwards compatibility.
Throwing stuff out tends to do that... :)
More information about the erlang-questions