[erlang-questions] illegal guard expression for IF illegal guard expression for "if"

[Barco You]

>For example, suppose you often want to match [{opt,X}].
>Then you will one day be able to write
>
 >      #one_opt(X) -> [{opt,X}].


Your 'abstract pattern' looks like macro!



On Tue, Dec 6, 2011 at 7:08 AM, Richard O'Keefe <ok@REDACTED> wrote:

>
> On 5/12/2011, at 3:57 PM, Daniel Dormont wrote:
>
> > In my experience with Erlang so far, this is perhaps the weirdest
> > feature for me from a language standpoint. I understand the
> > motivations, but at least from where I sit, it's a weird mental leap
> > from there to "we allow these few functions, but not others."
>
> In old Erlang, it was a lot clearer: the things that were allowed in
> guards were almost all things that were not allowed anywhere else.
> For example X < Y was allowed as a guard but not as an expression.
>
> To this day, I stick with "," and ";" in guards, reserving
> "andalso" and "orelse" for expressions (and trying to avoid those).
>
> > In fact,
> > not even all of the allowed functions are "pure" in the sense that,
> > say, a Haskell programmer would recognize. I'm specifically thinking
> > of node/0 and self/0.
>
> self() cannot change in a process.
> I don't believe node() can change either, but I could be wrong.
>
> > What are abstract patterns?
>
> Functions are abstractions of expressions.
> Abstract patterns are abstractions of patterns.
>
> For example, suppose you often want to match [{opt,X}].
> Then you will one day be able to write
>
>        #one_opt(X) -> [{opt,X}].
>
> and then use #one_opt(X) wherever you would have written the pattern.
> The proposal has been around for years, but the OTP team have always
> had more urgent maddened grizzly bears to stun.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111206/db465566/attachment.htm>