Note that because blocks in Julia are expressions, you can do multi-line expressions in comprehensions that you wouldn't be able to do in Python:

    [
       let y = x + 1
         z = 2y
         -z
       end 
       for x in 1:5
    ]

This specific case could be approximated with something like:

  >>> [(y:=x+1, z:= 2*y, -z)[-1] for x in range(1, 6)]
  [-4, -6, -8, -10, -12]

or, to state the obvious:

  def _(x): y = x+1; z = 2*y; return -z
  [ _(x) for x in range(1,6) ]

I can make sense of nested Python list comprehensions if I read them as shorthand for nested for loops, in which case you need to define variables in the outer loop before you can define dependent variables in the inner loop.

e.g. with your example above,

  for xs in xss:
      for x in xs:
          x

What's confusing about the syntax is that `x` in your example above comes first, whereas in actual nested loops it comes last. So maybe:

  [for xs in xss for x in xs : x]

Could be alternative syntax that moves `x` to the end?

That's actually how list comprehensions work in F#: that would become:

  [for xs in xss do for x in xs -> x]

(where -> is a shorthand for do yield) in practice (after 3 years of professional F#), when writing functional code i'd actually rather have the result first rather than last. I got used to reading code right to left with Haskell so that's what feels most natural to me

> Also Haskell gets the order of ‘<-‘ clauses wrong, so probably mine is a minority opinion.

That's probably so it's more in-line with do-notation:

  [x | xs <- xss, x <- xs]

is the same as:

  do { xs <- xss; x <- xs; return x }

Maybe writing statements backwards was deemed more confusing.

Personally, I don't really use list comprehension syntax, but maybe I would if they were backwards like you describe. It would make more sense with the position of the return value being to the left.

Haskell and Erlang basically go for mathematical notation. Python and Julia more or less go for how you read those notations.

I personally prefer math-like notation because I find it much more readable and composable.

  x, such as x is in xs, xs is in xss

  x | x ∈ xs, xs ∈ xss # my math is rusty
 
  [x | x <- xs, xs <- xss] # haskell, erlang is isimilar

  [ x for xs in xss for x in xs ] # python, julia, order might be different

As soon as you add conditions/filters on data, math-like notation wins hands down

Edit:

Since I don't know Haskell, apparently in Haskell the order is wrong. So, only Erlang gets it right (variables are upper case in Erlang):

  [ X || X <- Xs, Xs <- Xss]

> only Erlang gets it right... [ X || X <- Xs, Xs <- Xss]

I don't have much experience with Erlang, but that also seems wrong:

  1> Xss = [[1]].
  [[1]]
  2> [ X || X <- Xs, Xs <- Xss].  
  * 1:13: variable 'Xs' is unbound
  3> [ X || Xs <- Xss, X <- Xs].
  [1]

Damnit. I haven't used Erlang in a long time, but I should've known that.

So, no language does it "right".

Note that in Julia, ∈ is a synonym of `in`, so a minor improvement towards your preferred notation can be:

    [ x for xs ∈ xss for x ∈ xs ]

I'm with you on that minority opinion.

The "for" side mimics nested for loops structure, but then the output statement goes first (?!).

It's the same feel as MM/DD/YYYY date format: very widespread, yet absolutely asinine to anyone seeing it for the first time :)

I appreciate where you're coming from, but this particular order allows you to reuse a variable. E.g, in earlier pythons which didn't yet have ":=", the example given by the comment below yours could be written as:

  [ z for x in range(1,6) for y in [x+1] for z in [2*y] for z in [-z] ]

Obviously not the kind of style you'd want to see in written code, but ...

I thought the same about the ordering but on the other hand this order matches what you would write in the imperative case i. e.

    for xs in xss:
        for x in xs:
            ...

after many, many years of writing python i still get this wrong at times, because i instinctively expect `[x for x in xs for xs in xss]` to be the correct version!