As for recursion, the syntax you proposed doesn't say "recursion" to
me, it says "let's add more complexity to a syntax that already is
hard to fit on a line so we can turn a sequence into a series."
> Anyway, that makes this talking about computational accuracy sound
> like an argument for my proposal here, not against it.
Not as I see it. My point is that functions like accumulate already
get me as much of your proposal as I can see being useful in my own
applications, and so I'd rather spend effort on the inherent
complexity of accurate computation than on learning new syntax which
as far as I can see buys me no extra simplicity.
Consider the existing comprehension syntax. I use it all the time
because it's very expressive, it "looks like" what I would write in a
declarative mathematical definition, and the constructive alternative
is not a function call, it's a loop, in many cases with a nested if
test as well. However, when you try to express more than one loop
with a comprehension, you end up with a counterintuitive ordering
based on the current "this expands naturally to for loops and if
conditionals according to this simple rule" syntax, along with a
separation of the result expression from the loop where it's actually
produced. It's not obvious to me that use of comprehension syntax
beyond [ f(x) for x in y if g(x) ] is all that useful, but that very
basic form is extremely useful by itself.
If your proposal will help make more complex comprehensions easy to
understand, then you've got something I'd like to have. But I don't
yet see how it fixes that, and if not, I ain't gonna need it and I
don't want to have to explain it to my students when they ain't gonna
need it either.
itertools functions are widely used and generally well-thought-of.
Avoiding accumulate is a non-goal AFAIK. AIUI, Guido does think that
avoiding reduce is a goal, but I believe that's because he thinks the
semantics are just plain hard to understand. If your syntax is in
large part a substitute for reduce, I doubt he will like it more than
reduce just because it's syntax. (I do not speak for Guido; I offer
my observation in the hope it will help you prepare to present your
idea to him in the most favorable light.)
That is, comprehensions are clearly useful, and I use them in almost
every program I write. I still don't see when I'd ever strongly
prefer the syntax you propose to the itertools we already have, so I
don't care if it's a consistent extension. That doesn't mean it's not
useful to you or others, it just means I'm not convinced -- and so I
will not join the proponents. That's all.