mini julep: if x then y

[quinnj]

In various discussions, it has been suggested to allow syntax like:

if x then y

As a short-form "if" statement and as an alternative to the common:

x && y

syntax which leverages the short-circuiting && operator for conditionally executing y (with y often containing other side effects and not necessarily returning a Bool).

The main advantages to this if-then construct being: more legible code, relying less on abusing &&, and formally including an "if" statement form that doesn't require an end keyword.

It occurred to me the other day, that this syntax would also provide a convenient means for implementing #550, which would look like:

A = [if x % 2 == 0 then f(x) for x in 1:10]

Relying on the fact that if-then doesn't require an end keyword, which we would probably need in some form anyway even if we went with python-style guards:

A = [f(x) for x in range(10) if x % 2 == 0]

To be clear, the Julia guard syntax would essentially be doing a rewrite from:

A = [if x % 2 == 0 then f(x) for x in 1:10]

to

A = [Filter(x->x % 2 == 0, f(x) for x in 1:10)]

Also as a clarifying note, this would be allowing the guard syntax at the generator level as opposed to just the comprehension level (which matches what python allows as well).

[StefanKarpinski]

The Perl/Ruby-style if/for modifier syntax seems like it would mix better with this. In other words:

println("positive") if x > 0         # conditional execution
x^2 for x=1:100                      # generator
[ x^2 for x=1:100 ]                  # comprehension
x^2 if x % 3 == 0 for x = 1:100      # filtered generator
[ x^2 if x % 3 == 0 for x = 1:100 ]  # filtered comprehension

It also has benefit of having precedent in other languages, which the if-then without end syntax doesn't seem to.

[davidanthoff]

Just a side note on issue management: #6823 discussed exactly this issue. At some point it was closed without comment, I followed up asking why it was closed because clearly there hadn't been a consensus to close it, but never got a reply. Seems it would be more efficient to not close issues like #6823, otherwise these discussions will just go in circles and all the points in the original issue will be repeated again. Would probably have made sense to change the title of #6823 at some point, and then add this here.

[JeffBezanson]

Yes, good point. Indeed #6823 seems to be mid-discussion and probably should not have been closed.

[ararslan]

Maybe I'm in the minority since other languages have taken this approach, but I've always found the action coming before the condition to be really weird, e.g. println("positive") if x > 0. I guess it's more concise than if x > 0 println("positive") end but at least to me it comes at the cost of readability.

I think of it like a conversation:

Julia: "I'll print a string..."
Harold: "Awesome!"
Julia: "...but only if some condition is met."
Harold: "Oh. :("

versus

Julia: "If some condition is met, I'll print a string."
Harold: "Okay, cool."

[StefanKarpinski]

@ararslan: I don't disagree, which is one of the reasons this feature isn't in Julia despite the prior art in Ruby and Perl. However, it does mix much better with the for modifier syntax for generators and comprehensions, which is why I brought it up here.

[ararslan]

@StefanKarpinski Yeah agreed, it does mesh better with those. I'm still hopelessly attached to conditions preceding actions though. 😄 (But as I've found myself saying often recently, my opinion doesn't really matter; I'm just some guy.)

I suppose if you had something like

if x % 3 == 0 then x^2 for x = 1:100

then it isn't immediately clear that you're starting a comprehension/generator/thingamajig, because it also reads as though it can be grouped like

if x % 3 == 0 then (x^2 for x = 1:100)

i.e., if some condition then generator. I wouldn't mind

if x % 3 == 0 x^2 end for x = 1:100            # More obvious what's happening, IMO
filter(x -> x % 3 == 0, [x^2 for x = 1:100])   # Verbose, but... ¯\_(ツ)_/¯

I guess if the condition were to follow the action in a generator, I think I'd prefer a different keyword than if, for example where. Then it reads almost like a SQL query, e.g.

x^2 for x = 1:100 where x % 3 == 0

I think where makes it a little clearer that you're filtering the values of x produced by the for than if does.

[StefanKarpinski]

It seems nicer to me to have the data flow in a single direction, although in this case right to left rather than left to right.

[ararslan]

Can you elaborate on what you mean by that?

[StefanKarpinski]

The for 1:n "generates" values, the if x % 3 == 0 filters them and the x^2 transforms them – generators already flow right to left and to keep that flow the filter needs to go in the middle. If the if clause goes to the right of the for clause then data "flows" from the middle to the far right then to the far left, which is weird. If the if clause is on the left then the data "flows" from the far right to the far left to the middle. I know SQL puts the where clause to the right of the table names and the expressions to the left – because that reads more like English – but I've always found this annoying to read and I think that reading like English is not a heuristic that should be taken too far in programming language design.

[StefanKarpinski]

Things I don't like about if x then y:

1. It introduces the new then keyword.
2. It's shorter to write if x y end than if x then y; x && y is even shorter.
3. The then keyword is widely used in languages for the exact opposite kind of syntax: a multiline if syntax that requires an end keyword (or fi in bash, yuck).

[ararslan]

Oh yeah, I see what you mean now about the flow. That makes sense. Thanks for the explanation!

Would it be weird to be able to do

x^2 if x % 3 == 0 for x = 1:100

and not be able to do

println("positive") if x > 0

?

[quinnj]

All good points.

I actually really like the syntax @StefanKarpinski first proposed in his first comment. I'm mainly interested in having conditional generators, with a more general short-form if-form as a bonus.

[andyferris]

Regarding generators, I was reading the if (or where - I have no opinion on that) to be part of the range... it's creating an iterator x = 1:10 if/where x % 2 == 0, which is then combined with the expression on the left to create an Array (or generator).

In a sense, x = 1:10 where x % 2 == 0 is itself a generator for some kind of iterable. This could be stand-alone syntax, no?

I feel that filtering is somehow a different operation to the conditional if a then b statement. Filtering acts on the iteration range. When the if a then b is combined with the expression on the left of the generator I would expect it to emit nothing in the cases a was false. Compare what logically happens if I add brackets:

[(x^2 if i % 2 == 1) for i = 1:10] # [nothing, 4, nothing, 16, nothing, 36, nothing, 64, nothing, 100]
[x^2 (for i = 1:10 where i % 2 == 0)] # [4, 16, 36, 64, 100]

Taking @ararslan's examples, if we allow

println("positive") if x > 0

then IMHO it follows that

x^2 if x % 3 == 0 for x = 1:100

should probably emit nothing, nothing, 9, nothing, nothing, 36, ...

Finally, if we were to adopt a shorthand if conditional, my vote is for the condition before the statement, for the reasons outlined by @ararslan's first post - being the principal of least surprise in reading the code. (remember, if they say code is read more than written, then if a then b is better syntax then a && b even if the latter is shorter). It also means the two possible types of if inside the generator would be distinct - on the far left - with the expression - or on the far right - with the range.

As for tradition in Ruby/Perl, I feel its better to try and come up with the best solution rather than be bogged down by tradition. If it works and feels natural people will like it.

[andyferris]

Also, if we have if/where in ranges, do we need to be careful to make sure the range stays Cartesian for multidimensional generators?

# Make a circular array (filled with distance to center)
r = 5
[sqrt(x^2 + y^2) for x = -5:5, y = -5:5 where x^2 + y^2 <= r^2]

This is kind-of cool and kind-of awful!

[JeffBezanson]

I feel that filtering is somehow a different operation to the conditional if a then b statement.

Yes! I was about to post this same comment. Filtering operates on the iterator as a whole, and is not part of the computed expression inside.