Thomas Wouters wrote:
> But the syntax is pretty ambiguous, and not
> too pythonic at that. For instance, the endless mixing possibilities of
> 'for' and 'if' without delimiters or ways to group them can be pretty
> confusing.
I don't think it's so confusing if you think about LCs the right
way. You're meant to be able to think of them as a declarative
construct, e.g.
[(x, y) for x in a for y in b if y > 3]
means "a list of all tuples (x, y) such that x is in a and y
is in b and y > 3". Assuming no side effects, the result doesn't
depend on what order the loops and tests are nested in, so (unless
you're concerned about speed) you don't need to think in terms
of loops at all, just a set of conditions.
The syntax I chose was the most pythonic one I could think of
that worked. It would probably look better with some sort of
separator, but I wouldn't like to use anything stronger than
a comma (semicolons inside a statement just don't look right
to me), which means something like
[(x, y) for x in a, for y in b, if y > 3]
But then it looks a bit redundant having to repeat the
'for' each time, so you'd really want it to be more like
[(x, y) for x in a, y in b, y > 3]
which is hopelessly ambiguous. So I gave up on commas altogether.
> it would be nice if list comprehensions could be used to initialize
> *part* of a list,
It would, but would the greatly increased implementation complexity
be worth it? (And don't forget to allow range-literals the same
privilege!-)
> Can we get away with not including the nested-for syntax?
I'd be really disappointed if LCs only made it in in such an
emasculated form. It would remove a huge amount of their power, and I
would have serious doubts that what was left would be worth bothering
with.
Heavens, next thing you know, someone will suggest adding a lambda
without nested scoping... :-)
> parallel-for-loops -> list comprehensions -> range-literals
That's sensible, but I wouldn't like to see LCs get held up
waiting for a consensus on PFLs to emerge. I think that if we
just make sure that LCs and normal FLs share the same
piece of compiler code, whatever is done to FLs later will
get inherited by LCs automatically... sort of...
Concerning PFLs, it seems to me that earlier language design
decisions have pretty well scuttled any hope of coming up with
a natural-looking and compatible PFL syntax. So we're going to
have to settle for (a) an incompatible one, (b) an unnatural
looking one, or (c) none at all.
In category (b), my suggestion of the day is:
for {var, ...} in expr
e.g.
for {x, y} in a, b
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. |
greg@cosc.canterbury.ac.nz +--------------------------------------+
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4