Re: [Groff] parsing a corner specification

[Joel E. Denny]

On Tue, 21 Aug 2007, Werner LEMBERG wrote:

> > > Patches are highly welcome :-)
> > 
> > I wouldn't mind writing a patch once I'm sure of which behavior is
> > best.  My lack of practical experience with pic leaves me reluctant
> > to make a judgement call yet.
> 
> Well, it seems that you've hit a behaviour which is (a) quite obscure
> since there has never been a report about it, (b) which doesn't work
> in AT&T pic and Dwight's dpic anyway, and (c) which can be
> circumvented easily.  Feel free to remove it completely in case it is
> the most convenient solution.

I've been exploring the source more to try to figure out how to do this.  
In the process, I've made a few new discoveries that lead me to believe I 
am dealing with an *intended* GNU extension that is broken in some 
contexts because of the use of LALR(1) parsing.

First, I discovered this comment in pic.y:

  /* give this a lower precedence than LEFT and RIGHT so that
     [A: box] with .A left == [A: box] with (.A left) */

Thus, in some contexts, gpic does intend to interpret "left" as a corner 
even without a ".", "of", "upper", or "lower".  Here's a complete example:

  .PS
  B: box "B";
  [A: box "A"] with .A left at B;
  .PE

It generates the figure I expect: A's left corner at B's center.  In other 
words, the following is equivalent:

  .PS
  B: box "B";
  [A: box "A"] with .A.w at B;
  .PE

Second, as Ted Harding pointed out, sometimes gpic interprets "left" as a 
direction when the "upper" or "lower" keyword can make gpic interpret it 
as a corner instead.  For example:

  .PS
  A: circle
  line at A left;
  .PE

That draws a line pointing to the left from the center of A.  However:

  .PS
  A: circle
  line at A upper left;
  .PE

draws a line pointing to the right from the upper left corner of A.

In other words, "line at A left" is ambiguous until precedence 
declarations are considered, and they prefer the direction interpretation.  
Here's a source code comment to support this conclusion:

  place:
        /* line at A left == line (at A) left */
        label                                         %prec CHOP
                { $$ = $1; }

Third, there are cases where the interpretation of "left" alone is 
unambiguous and it should be interpreted as a corner, but it's a syntax 
error instead.  My original example in this thread is such a case:

  .PS
  A: circle "A"
  B: A left
  circle "B" at B
  .PE

I see no ambiguity because I don't see how it makes sense to reference an 
existing object with a direction modifier.  That is, even if A referenced 
a line, its direction was chosen when it was drawn.  Thus, it's clear to 
me that "B: A left" means set the label B to the left corner of A.  Of 
course, "B: A upper left" means set the label B to the upper left corner 
of A.  The only reason that "B: A left" is a syntax error is because of 
the use of LALR(1).  Canonical LR(1) would parse it correctly.

Does this view seem reasonable to everyone?