bison-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Visibility and error messages (in named refs).


From: Alex Rozenman
Subject: Re: Visibility and error messages (in named refs).
Date: Sat, 18 Jul 2009 23:02:38 +0300

Hi Joel,

I think the main confusion for the user will be understanding why a
> reference he wrote is rejected when it is perfectly valid and unambiguous.
> That's why I had suggested that Bison always report "misleading reference"
> in these cases.  Based on your previous email, that's why I'm also now
> suggesting that a misleading reference always be just a warning.  Bison is
> just telling the user that something *may* be wrong.    I also do not think
> we should drop the "hidden" warnings.


I think we all agreed now that the "misleading reference" will be a warning.
Now, my biggest (and sole) concern is the following: would we like to give
warnings in the following cases:

stmt[result] : IF expr THEN stmt;
{ $result = create_if_stmt($expr, $stmt); }

if_stmt : IF expr THEN stmt[then] ELSE stmt;
{ $$ = create_if_stmt($expr, $then, $stmt); }

Currently, my intuitions says not to issue any warnings (compile smoothly)
in the first case, and give a "misleading reference" warning in the second
case. This probably because I started with not including LHS at all and my
brain just refuses to change the view. I just afraid that this single issue
will cause to multiple complains from users and we will be forced to change
it anyway.
Akim, could you please give you opinion ?

I think it's confusing and not helpful to the user if Bison makes it an
> error only in
> some subcases.
>
Sub cases are our implementation detail. I'm not sure users will be ever
aware of a similarity between these situations. We are free to decide about
the behavior in each specific case.


Best regards,
Alex Rozenman (address@hidden).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]