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

[Akim Demaille]

Le 18 juil. 09 à 22:02, Alex Rozenman a écrit :

> 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'm in favor of being really strict about this, and I would make these  
errors.  The question probably roughly amounts to whether we should  
encourage to name the symbols, or to maximise the possibility to use  
the default symbol names.  Of course the [] to name the symbols does  
pollute a bit the rules themselves.  Maybe an additional means to  
refer to symbols could help?

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


or something like that?

No, really I prefer that we stick to a single system.  And I share  
Joel's opinion: let's not make exceptions, exceptions are the painful  
parts of the rules.  So let's treat both sides of the rule equally.

Besides, I still have vaguely in a (dark) corner of my mind the idea  
to try one day to introduce explicitly the "backward context" in the  
rule to provide a better alternative to $0, $-1 and so forth.  It  
could appear on the lhs too, so there would be more than one symbol on  
the lhs, in which case the exception for $$ would hardly make sense.

Not a strong point here, I agree :)