Re: undiagnosed pic error

[G. Branden Robinson]

Hi Doug,

At 2023-06-11T19:59:46-0400, Douglas McIlroy wrote:
> The fact that you can't apply "fill" to a polygon drawn with pic's
> "line" command is a minor symptom of a general phenomenon. Pic accepts
> any modifier attached to any command that admits some modifier, and
> simply ignores those that don't make sense. A couple of examples:
>         box rad 1
>         box with .e at last box .w with .w at last box .e

It appears to me that this is the fault of the way the yacc grammar for
GNU pic is written.  There is a big rule for `object_spec` that applies
all modifiers generically to all objects, setting flags that are
(eventually) honored or ignored by the objects in question.

https://git.savannah.gnu.org/cgit/groff.git/tree/src/preproc/pic/pic.ypp#n642

One could try to catch the problem by having the objects themselves
check for the setting of irrelevant flags, but that feels like the wrong
level at which to solve the problem.  I don't understand pic well, but
if there is some means of heritability for any of these attributes, then
emitting warnings at that level seems to run a great risk of producing
false positives.

As I think you are implying, it is surely better to catch these at the
time the input is parsed.  I must confess that I don't regard myself as
au fait with yacc (the "hoc" chapter of Kernighan & Pike's _The Unix
Programming Environment_ was the one that took me the longest, by a
significant margin[1]).

Without further guidance, my approach would be to subdivide object_specs
by the kinds of modifiers they can take.  Something like this:

  rectilinear_object // takes HEIGHT and/or WIDTH
  round_object // takes RADIUS and/or DIAMETER

...and, uh, I have to pause here because I don't understand pic well
enough.  Maybe something like `placeable_object` for objects that can
take relative placements.

Anyway, the rest of the idea is that, once the various pic objects are
organized into this class hierarchy (if you squint at it), then rules
can be introduced so that an `object_spec` that isn't a `round_object`
gets a rule that produces a `lex_error()`.  I might also need a better
command of how to specify precedence in yacc.

It will probably be months before I have enough yacc and pic knowledge
to undertake this.  But what do you think of the approach?  If it is
sound, maybe someone who already knows their way around both tools can
chip in.

Regards,
Branden

[1] Part of that was the fault of flex and bison being way less tolerant
    of a casual approach to input than old lex and yacc were.  This is
    the only part of that book that I found painful and difficult to
    adapt to modern *nix environments, and it's all down to tooling
    support.

signature.asc
Description: PGP signature