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?
