[Fenichel]

Named parameters, subroutines, math functions, and miscellaneous control structures (if/endif, repeat/endrepeat, do/while, while/endwhile, break, continue) are explicitly deprecated by Tormach, with the claim (Section 7.9 of my 770 manual; probably similarly located in other manuals) that such code is "difficult to debug and very difficult for another operator to understand."
This is backward. For example, the PP's conversational facilities let me generate gCode to do external thread milling of two 1/4-20 threads, located at (0,0) and (1,1). The resulting code (579 lines) is in the attachment. Most of its lines are nearly-repetitive blocks of which

(Pass 5)
G0 Z 1.5099
G1 X 1.3610
F 16.92 (Arc Feed, inches/minute)
G2 X 0.7079 Y 0.7878 Z 0.3399 I -0.3610 J 0.0000 P 24
F 10.00 (Feed, inches/minute)
G0 X 0.6870 Y 0.7726
G0 Z 2.0000
G0 X 1.3869 Y 1.0000

(Pass 6)
G0 Z 1.5092
G1 X 1.3598
F 16.95 (Arc Feed, inches/minute)
G2 X 0.7090 Y 0.7885 Z 0.3392 I -0.3598 J 0.0000 P 24
F 10.00 (Feed, inches/minute)
G0 X 0.6870 Y 0.7726
G0 Z 2.0000
G0 X 1.3869 Y 1.0000

are typical. As seen here, some of the numbers are the same from block to block, some are related to each other in simple arithmetic or trigonometric ways, but others are completely obscure. To call this sort of code easy to debug seems crazy, and it's hard to see how anyone might read it to learn about the considerations involved in thread milling. If a user wanted to revise this code (say, by adding another thread, or by moving the second thread from (1,1) to (1,2)), then trying to edit the changes into the code would be hopeless. A more ambitious revision (suppose that one of the bosses to be threaded were near an obstruction, so that the tool's escape path at the bottom of the thread had to be more complex than a radial move followed by a straight move up) would be out of the question. The only way to do any revision would be to go back to the PP conversation.
I have tried to reverse-engineer this code, and to rewrite it using techniques which would be considered elementary in any other programming environment. The reverse engineering was incomplete, because

• The initial feed rate used for cutting the thread is larger than the user-specified feedrate by a factor whose origin is obscure.
• On successive passes cutting each thread, PP slightly increases the feed rate along the arc, presumably to maintain chip load. I didn't figure out what calculation PP uses for this.
• Successive passes are cut more deeply, in a progression determined obscurely.

If these gaps could be filled, the resulting code would be much tighter and more comprehensible.
With these gaps in my understanding, the resulting code (attached) had to carry forward a little of the obscurity & verbosity of the original. Still, the revised version is about one third the size of the PP-generated code. It is more accurate than the PP-generated code, because some pass-to-pass changes in the PP-generated code should be monotonic, but aren't, presumably because of rounding errors in reducing the floating-point calculations to 4 decimal places for PP's ASCII output. The recoded version is in some ways easily modified: to change the location of the second thread from (1,1) to (1,2), and to add a new thread at (3,2), one would need only to change its lines 62 & 63 from

#<_XCenter> = 1  #<_YCenter> = 1         ; second thread
M98 P1000                                ; ..

to

#<_XCenter> = 1  #<_YCenter> = 2         ; second thread
M98 P1000                                ; ..
#<_XCenter> = 3  #<_YCenter> = 2         ; third thread
M98 P1000                                ; ..

One potential objection to this sort of gCode is that by moving the trigonometric calculations from preparation time to machining time, the code will take so much longer to run that the machine operations will be slowed or even compromised. This objection is almost surely unrealistic, given the speed of typical controllers. For example,

#101 = 0
o1000 repeat [100000]
#101 = [#101 + 0.01]
#102 = [cos[#101]]
o1000 endrepeat

runs on my controller in about 7 seconds.
A more serious potential objection is that PathPilot might be used to prepare gCode for controllers in which modern gCode is not supported, or that one might want to submit code prepared by PP to a less capable simulator (for example, to the linguistically-challenged simulator in the GWizard editor).