[erlang-questions] erlang *****

Robert Virding rvirding@REDACTED
Mon Mar 17 23:31:06 CET 2008


When I was checking through trapexit.org after I had posted my reply I found
that in trapexit mr mail had been truncated after the 3rd clause of foo. Did
this happen to everyone else as well, a possible gmail bug, or was this only
at trapexit, a trapexit bug? We'll see if it gets through uncut into
trapexit as quoted text.

Robert

On 17/03/2008, Robert Virding <rvirding@REDACTED> wrote:
>
> One thing that has to be considered in this discussions are guards. Guards
> are, irrespective of how some people would like to view them, part of
> pattern matching but those bits which can be difficult to express in a
> pattern*. As the guard varies with the pattern then they have to be kept
> together, something like:
>
> foo(Pat11, ...) when Guard1 ;
> foo(Pat12, ...) when Guard2 ;
> foo(Pat13, ...) when Guard3 ->
>     ...;
> etc.
>
> Having no "-> Body" after the pattern/guard means that you share the same
> body as the following clauses down to a clause with a body. In case/receive
> it would look something like:
>
> case ... of
>     Pat1 when Guard1 ;
>     Pat2 when Guard2 -> ...;
>     ...
> end
>
> This is just a suggestion to both include patterns, which you must, and
> not introduce any new syntax. It also looks a bit more Erlangy. I haven't
> tried modifying the parser but it will probably need modification of the
> AST. I don't think there would be any problems in compiling this, or an
> equivalent.
>
> I remember that Richard's abstract patterns would also do this but here it
> would just be more explicit and dynamic.
>
> Robert
>
> * I have seen attempts to bake in guard tests into patterns but I think
> they become largely unreadable and manage to effectively hide the actual
> pattern.
>
>
> On 17/03/2008, Andras Georgy Bekes <bekesa@REDACTED> wrote:
> >
> > > But now consider
> > >
> > >       f({X,_}\/{_,X},
> > >         {Y,X}\/{X,Y},
> > >         ...
> > >         {Z,W}\/{W,Z}
> > >       )
> >
> > So matching this pattern must involve backtracking. Awww.
> >
> >
> > > You could hack around this by requiring that if a head variable is
> > > bound in a disjunctive pattern it is not matched by any other head
> > > pattern.
> >
> > The problem does exist in a single pattern:
> >
> >          {{X,_}\/{_,X},
> >           {Y,X}\/{X,Y},
> >           ...
> >           {Z,W}\/{W,Z}}
> >
> >
> > We could of course generalise the above restriction, but it doesn't make
> > it tolerable.
> >
> > But what are the real problems with the search for the right match with
> > backtracking? If the programmer has written that silly pattern, he/she
> > should be aware that it might not be very fast. Are there consequences
> > other than the match being slow?
> >
> >
> > > I note that my abstract pattern proposal *already* gives you
> > > disjunctive patterns, BUT in such a way that the disjunctions can't
> > > interact like this.
> >
> > Could you give some reference?
> > I've searched for "abstract pattern" in the archives and found a few
> > mail, but not your paper.
> >
> >
> >         Georgy
> >
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://www.erlang.org/mailman/listinfo/erlang-questions
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080317/ce3822d7/attachment.htm>


More information about the erlang-questions mailing list