Maybe it's just I who don't understand how to read the
doc on abstract forms, but quoted from
http://www.erlang.org/doc/doc-5.5.4/erts-
5.5.4/doc/html/part_frame.html
"If C is a function clause ( Ps ) when Gs -> B where
Ps
is a pattern sequence, Gs is a guard sequence and B
is a body, then
Rep(C) = {clause,LINE,Rep(Ps),Rep(Gs),Rep(B)}.
...
A guard Gs is a nonempty sequence of guard tests G_1, ...,
G_k, and Rep(Gs) = [Rep(G_1), ..., Rep(G_k)].
...
If G is true, then Rep(G) = {atom,LINE,true}.
...
If G is an operator expression E_1 Op E_2, where
Op is a binary operator, and E_1, E_2 are guard
expressions, then
Rep(G) = {op,LINE,Op,Rep(E_1),Rep(E_2)}. "
I read this as
Rep(C) = {clause,LINE,Rep(Ps),Rep(Gs),Rep(B)}
Rep(Gs) = [Rep(G)|...]
Rep(G) = {op,LINE,Op,Rep(E_1),Rep(E_2)}|...
In other words, as if
Guard = [{op,1,'==',{integer,1,1},{var,1,'R'}}]
would actually be valid.
BR,
Ulf W
> -----Original Message-----
> From: Bjorn Gustavsson [mailto:bjorn erix.ericsson.se]
> Sent: den 3 april 2007 10:31
> To: Ulf Wiger (TN/EAB)
> Cc: erlang-bugserlang.org
> Subject: Re: [erlang-bugs] compile and syntax_tools
disagree
>
> As far as I understand, The ERTS User's Guide says that
> you'll need two layers of lists to represent a guard
sequence.
>
> syntax_tools still accepts the older format of guards
(before
> semicolons in guards were introduced), so that it can
still
> be used for the abstract format in old Beam files.
>
> So as I see, there is no bug.
>
> /Björn
>
> "Ulf Wiger (TN/EAB)" <ulf.wigerericsson.com> writes:
>
> > I'm getting a bit cross-eyed, but this has got to
be a bug
> *somewhere*:
> >
> > 12> M =
>
[{attribute,1,module,m},{attribute,1,export,[{foo,1}]}|Fs]
++
> > [{eof,1}].
> > [{attribute,1,module,m},
> > {attribute,1,export,[{foo,1}]},
> > {function,1,
> > foo,
> > 1,
> > [{clause,1,
> > [{var,1,'R'}],
> >
[{op,1,'==',{var,1,'R'},{integer,1,1}}],
> > [{atom,1,true}]}]}, {eof,1}]
> > 13> compile:forms(M).
> > .:none: internal error in expand_module; crash
reason:
> > {function_clause,
> > [{erl_expand_records,
> > guard_tests1,
> >
[{op,1,'==',{var,1,'R'},{integer,1,1}},
> > ...
> >
{erl_expand_records,guard_tests,2},
> > {erl_expand_records,guard,2},
> >
{erl_expand_records,clauses,2},
> > {erl_expand_records,forms,2},
> > {erl_expand_records,forms,2},
> > {erl_expand_records,module,2},
> > {sys_pre_expand,module,2}]}
error
> > 14> M1 =
>
[{attribute,1,module,m},{attribute,1,export,[{foo,1}]}|Fs1]
> > 14> ++
> > [{eof,1}].
> > [{attribute,1,module,m},
> > {attribute,1,export,[{foo,1}]},
> > {function,1,
> > foo,
> > 1,
> > [{clause,1,
> > [{var,1,'R'}],
> >
[[{op,1,'==',{var,1,'R'},{integer,1,1}}]],
> > [{atom,1,true}]}]}, {eof,1}]
> > 15> compile:forms(M1).
> > {ok,m,
> >
> >
>
<<70,79,82,49,0,0,1,184,66,69,65,77,65,116,111,109,0,0
,0,50,0,0,0,6,1,
> > 10
> > 9,
> > ...>>}
> >
> > When pretty-printing the two form lists using
> erl_prettypr:format/2,
> > you get the same output, and according to the ERTS
User's
> Guide, the
> > two guard representations should be equivalent. A
list of
> lists in the
> > Guard represents a disjunction, and a list of
Guard expressions
> > represents a conjunction. In this case, there's
only one guard expr.
> >
> > 6>
erl_prettypr:format(erl_syntax:form_list(Fs)).
> > "foo(R) when R == 1 -> true."
> > 6>
erl_prettypr:format(erl_syntax:form_list(Fs1)).
> > "foo(R) when R == 1 -> true."
> >
> > It seems to me as if the bug is in the compiler
(version 4.4.3).
> >
> > Forgive me for not diving into the compiler source
code to
> verify this
> > claim. Time to put the kids to sleep.
> >
> > BR,
> > Ulf W
> > _______________________________________________
> > erlang-bugs mailing list
> > erlang-bugserlang.org
> > ht
tp://www.erlang.org/mailman/listinfo/erlang-bugs
>
> --
> Björn Gustavsson, Erlang/OTP, Ericsson AB
>
_______________________________________________
erlang-bugs mailing list
erlang-bugserlang.org
ht
tp://www.erlang.org/mailman/listinfo/erlang-bugs
|
