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
