Julia: for syntax without a variable

[StefanKarpinski]

Especially with comprehensions I do this by accident fairly often:

``` .jl
[@elapsed f() for 1:10]

We could support the same for loops:

``` .jl
for 1:10 f() end

Not super crucial, but seems like something we might as well allow.

[diegozea]

Looks easy to read +1

repeat 10 f() end is a bad idea, isn't ?

[ViralBShah]

I like this.

[StefanKarpinski]

cc: @nanosec – if you're bored and looking for something to hack on since you know your way around the parser code pretty well after doing the 128-bit integer and bigint thing.

[ihnorton]

This works with both for 1:10 ... and comprehensions:

diff --git a/src/julia-parser.scm b/src/julia-parser.scm
index c7d44b9..25ce54e 100644
--- a/src/julia-parser.scm
+++ b/src/julia-parser.scm
@@ -1216,6 +1216,8 @@
                      r)
                     ((and (pair? r) (eq? (car r) 'in))
                      `(= ,(cadr r) ,(caddr r)))
+                    ((eq? (car r) ':)
+                     `(= ___secretz_local_i ,(values r)))
                     (else
                      (error "invalid iteration specification")))))
        (case (peek-token s)

[StefanKarpinski]

That seems ok but maybe not fully general. I guess to be conservative, we can only allow literal ranges for this.

[lindahua]

For a statement like for 1:10 f() end. It seems even the 1 in 1:10 is redundant. To express the idea of executing something for 10 times, wouldn't it be more convenient to write

@repeat 10 f()

Implementation of such a macro should be trivial.

[stevengj]

I'm a little skeptical of this; I prefer to err on the side of conservatism when it comes to adding new syntax, and there doesn't seem to be a pressing need for this … it just saves you from typing two characters (for _=1:10 vs. for 1:10), nor does it make Julia more consistent.

[prcastro]

+1 This is a very nice syntatic sugar, and make some for loops very readable

[ScottPJones]

I think the @repeat n expr syntax is the cleanest, just saying!

[KristofferC]

Seems this is likely not to happen. Also, _ is deprecated for rvalue-usage so for _ = 1:10 seems good enough.