On Thu, Jul 22, 2010 at 3:55 PM, Terry Reedy wrote:

On 7/22/2010 4:38 AM, geremy condra wrote:

...

On Wed, Jul 21, 2010 at 9:21 PM, Terry Reedy  wrote:

...

...

e = fe(a,b,c, p1) where:  c = fc(a, d, p2 where:    d = fd(a, p1) where:      a = fa(p1, p2)  b = fb(a,p2)

where p1,p2 are input parameters;

looks about as bad (and it was a real effort to write). I would rather something like that were in a branch dialect, Ypthon with its own extension (.yp).

Of course it looks bad. You can make anything look bad. 37 levels of nested 'for' statements look bad. That isn't an argument against this, it's an argument against bad code period.

I think you make an unfair comparison: 3 nested where statememts, which you agree look bad, against 37 nested for statements, which I would agree would be bad, as in unreadable. (I believe auto code generators have done such things.) The fair comparison would be 3 nested where statement, which you agree is bad, against 3 nested for statements, which is routine and not bad. So I think you made my point ;-).

Hmm. I'm pretty sure you know that I don't think 37 levels of for statements is the minimum required number for ugliness, which makes me wonder why you chose to structure an argument around that idea unless you just wanted to score a few easy points on an otherwise valid claim. I would also argue that the more valid comparison would be nested functions or classes- both perfectly pretty constructs on their own- which would cause me to gnaw on otherwise unoffending office furniture if I encountered them nested 3 deep.

My differently wired brain would tolerate the new construct much better, and might even use it, if nested where/given constructs were not allowed.

Seems easier to work with to me, but I don't see the point in increasing the implementation difficulty just to stop bad programmers from writing bad code. Geremy Condra