[erlang-bugs] parser/preprocessor bug
Robert Virding
robert.virding@REDACTED
Wed Nov 23 00:11:17 CET 2011
My opinion is, as everyone has probably guessed, is to revert back to what it was before. I don't think that the extra parentheses were worth worrying about.
It was actually exactly the opposite with the trailing parenthesis in macro definitions. That was laziness on my part on not bothering to add an extra test for that case.
Revert the parentheses, or at least add a warning which will cause people to put them back.
Robert
----- Original Message -----
> On Mon, Nov 21, 2011 at 2:02 PM, Raimo Niskanen wrote:
> > On Fri, Nov 18, 2011 at 09:51:08PM +0000, Robert Virding wrote:
> > > Originally the parentheses were mandatory but then the need for
> > > them around an record expression was removed to "improve" the
> > > syntax. Only in some cases though. Sorry for griping but I think
> > > it
> > > was a bad change. Other people have had exactly the same errors.
> >
> > Yes. It has now become a pitfall worth repeating.
> >
> > The intention was to improve (simplify) the syntax for nested
> > records e.g:
> > Y = X#outer_record.a#inner_record.b
> > was syntactically invalid and had to be written:
> > Y = (X#outer_record.a)#inner_record.b
>
> Even though I took the original patch and reworked it for inclusion
> in
> OTP, seeing the user confusion and misuse, I'd like to see the
> changes
> reverted.
>
> Could it be that during the review by the OTP board the potential
> issues Jesper and Joe ran into have been missed?
>
> If we want to keep it, is there a reliable and correct way to
> generate
> a syntax error/warning or limit the paren-less record access in
> erl_parse.yrl? If not, I think it's best to revert the changes.
>
> This reminds me of the missing check for a closing paren in macro
> definitions. That has been fixed and I think this should also be
> fixed. I also don't think the patch is worth the trouble it has
> caused.
>
> Relevant commits: 3829e5 and 45c380d
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs
>
More information about the erlang-bugs
mailing list