Julia: Add comment macros to disable next expression.

[SalchiPapa]

This is very common in Lisps:

macro comment(block) end
macro %(block) end    # inspired in Matlab % comments

Which can be used like this for example:

julia> begin
           println("foo")
           begin
               println("bar")
               println("baz")
           end
           for i in 1:3
               println("qux", i)
           end
       end
foo
bar
baz
qux1
qux2
qux3

julia> begin
           @% println("foo")
           begin
               println("bar")
               println("baz")
           end
           for i in 1:3
               println("qux", i)
           end
       end
bar
baz
qux1
qux2
qux3

julia> begin
           println("foo")
           @% begin
               println("bar")
               println("baz")
           end
           for i in 1:3
               println("qux", i)
           end
       end
foo
qux1
qux2
qux3

julia> begin
           println("foo")
           begin
               println("bar")
               println("baz")
           end
           @comment for i in 1:3
               println("qux", i)
           end
       end
foo
bar
baz

julia>

What do you thnk? do we want/need this? If so, where should I put them in a PR, in base.jl?

[SalchiPapa]

@johnmyleswhite could you share why you dislike this? 👎 without comments is not constructive at all. You don't like the names? That can change.

Adding more references:

• http://stackoverflow.com/a/1191661/2374329

Clojure supports a #_ reader macro which completely skips the next form.

In Clojure:

(comment ...)

and also:

• http://clojure.org/reference/reader#_comment

Ignore next form (#_)
The form following #_ is completely skipped by the reader. (This is a more complete removal than the comment macro which yields nil).

• http://stackoverflow.com/a/1191648/2374329

Clojure supports a #_ reader macro which completely skips the next form.

[SalchiPapa]

This goes along what other reader macros do in lisps, it returns nothing:

julia> macroexpand(quote                         
           begin                                 
               println("foo")                    
               @% begin                          
                   println("bar")                
                   println("baz")                
               end                               
               for i in 1:3                      
                   println("qux", i)             
               end                               
           end                                   
       end)                                      
quote  # REPL[5], line 2:                        
    begin  # REPL[5], line 3:                    
        println("foo") # REPL[5], line 4:        
        nothing # REPL[5], line 8:               
        for i = 1:3 # REPL[5], line 9:           
            println("qux",i)                     
        end                                      
    end                                          
end                                              

[johnmyleswhite]

👎 without comments is not constructive at all

It's not a coincidence that GitHub added +1 and -1 reactions: they're a better method for organizing decision-making than eliciting lots of verbal responses when you just need to count votes.

I think Julia does not need yet another way to comment things out. I wish we hadn't added multiline comments and don't want to see us add a second form of multiline comments that is even more non-local than the current form and depends more strongly on Julia's syntax rather than simple textual properties.

[SalchiPapa]

Thanks for taking your time to answer! I think 👍 are great when people agree on the same stuff that has already been discussed, but 👎 should at least state why they don't agree IMO because we can't tell what you dislike since that has no discussion and no way of telling what could be better.

What do you mean by non-local? I care about ease of rapid prototyping ideas at the REPL for example, even if you comment with multi line comments, it's not pretty, not as easy as adding one of this macros and test again, whatever you where doing. With multi line comments, you have to keep track of the beginning and end of a block and annotate at those points, when reverting, you have to do the same, remove the opening and closing comments at those points.

[johnmyleswhite]

The problem is that if you're too eager when optimizing for "rapid prototyping ideas at the REPL" you eventually start to make the language hard to use when writing large codebases.

That's what the concern about non-locality is focused on. Consider the following code template:

@comment begin
    println(1)
    println(2)
    [...]
    println(N - 1)
    println(N)
end

Imagine that N = 100. Then it's likely that when you look at a screen of text (which is the local amount of code you're reading while trying to understand that code) you won't see that there's a comment macro at the start of the block. This is the problem: the relevant information that tells you how to interpret the code isn't near the code -- it occurs arbitrarily far away. That's pretty bad for someone who's trying to learn about a codebase they didn't write and it's far worse for a person who has to reason about a codebase by searching through the code for function names they care about.

Basically your proposal is optimizing for people writing code at the expense of people reading code. Since we already have one such construct, I would prefer not adding another such construct.

[SalchiPapa]

Thanks again for your input, now I think I understand your opinion very well and I have also learned something new, non locality could be certainly an issue in large code bases and this could be abused just as well as any other feature as you are afraid (I certainly wasn't considering on abusing this myself).

I'm not so sure how bad non-locality would be in practice, since we already annotate with macros arbitrary large blocks of code, yet I think this would be far more useful with tooling support ie. change the color of a commented block of code, so we know it's been commented out, just glancing at it.

Your point about having already two ways of commenting code is very valid and it's what I expected to be the greatest deterrent for this idea, but I'll have to take into account non-locality more from now on in anything I do.

I'm very curious what others think about this kind of stuff.

[KristofferC]

Can it be highlighted without access to a julia parser?

[SalchiPapa]

Closing this issue, since the macro is easy to define, and tooling is needed for highlighting support.