Enhanced type guard syntax]

Chris Pressey cpressey@REDACTED
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
> something
> > away "
> >
> >   What are we going to chuck away?  Well not "when ->" ...  Since
> >   you can't
> say
> > 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

becomes

  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... :)

-Chris



More information about the erlang-questions mailing list