groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] pic problem


From: Ted Harding
Subject: Re: [Groff] pic problem
Date: Wed, 14 Jul 2004 11:05:50 +0100 (BST)

On 14-Jul-04 Ted Harding wrote:
> On 14-Jul-04 Larry Kollar wrote:
>> Interesting... have I actually uncovered a bug?
> 
> Not necessarily! Like many of the things developed by the original
> creators of Unix, 'pic' was a masterpiece of minimal design: you are
> given just what you need in order to be able to do almost anything,
> but you are not given any more. So, in order to do something weird
> and wonderful, you have a good bit of work ahead of you; but you can
> do it. This minimality was, of course, a merit in the old days of
> limited machine resources.
> 
> Therefore it is quite possible that the logic of the "for" loop
> in 'pic' was intentional: all you need is a variable which takes
> the required number of steps, through a sequence of known values.
> You can then transform these values to what you need within the
> loop (as in Heinz-Jürgen's solution).

I should have added to the above: The only defect in this "minimal"
implementation of the "for" loop is that, as far as I can see, it
was not documented! I can see no reference to its detailed behaviour
in the PIC User Manual (CSTR 116 by Brian W Kernighan, 1991 revision).

I think this was a definite oversight, since most Unix users by then
would have been familiar with the C logic:

  for( n = a; n <= b ; n += c ) {...}

for a loop with increasing (c > 0) values of n, or

  for( n = a; n >= b ; n += c ) {...}

in the contrary case, and might have expected 'pic' to have tested
at least whether c > 0 or c < 0, unless documented to the contrary.

While the Unix software was often admirably minimalist, the documentation
was unfortunately sometimes sub-minimalist. The intention was no doubt
minimalist, in that the user was expected to be able to solve the
logical puzzles implied in determining from the documentation what
was possible and what was not possible, but on occasion (and this is
true of the troff documentation as well) things you needed to know
in order to resolve logical ambiguities were sometimes not stated.
This looks like one of those.

Best wishes to all,
Ted.


--------------------------------------------------------------------
E-Mail: (Ted Harding) <address@hidden>
Fax-to-email: +44 (0)870 167 1972
Date: 14-Jul-04                                       Time: 11:05:50
------------------------------ XFMail ------------------------------


reply via email to

[Prev in Thread] Current Thread [Next in Thread]