VSCode Extension Replaces Pipes with Function Calls

[ParadaCarleton]

Even with the setting turned off, VSCode replaces pipes with function calls.

It also does this when not appropriate -- I'm using Tullio, and @tullio uses the pipe to indicate functions that should be applied after reduction. This means @tullio x := y[i] |> f is not the same as @tullio x := f(y[i]) -- the former takes a sum, then applies f, while the latter applies f and then takes a sum. Similarly, macros that take keyword arguments (like @tullio) have spaces inserted, even when the settings specify that keywords should not have spaces. To deal with situations like this, maybe there should be an option to disable formatting of lines that have a macro on them that's not defined in base?

[ParadaCarleton]

Worth noting -- a good heuristic that would deal with most cases of macros that have keyword arguments is to check whether there's multiple "assignments" on a single line; if so, avoid formatting spaces for assignment. For instance, I have:

@tullio threads=false weights[y] = exp(log_like[x] - log_like[y]) |> inv

The fact that I have 2 assignments on the same line indicates that one of them is probably a keyword argument, since multiple assignments on one line is invalid syntax otherwise.

[ParadaCarleton]

Figured it out -- looks like the problem is that VSCode arguments were being overwritten by the blue style guide, and I needed to change the setting to override the style guide.

The other comments about macros still hold, I think.

[domluna]

so if i understand this right then this option should not be applied within a macro call?

[ParadaCarleton]

so if i understand this right then this option should not be applied within a macro call?

Which option? If you're referring to spaces around =, then yeah -- a lot of macros accept keyword arguments that shouldn't be spaced.

The thing with pipes works fine, I think. Maybe it could be made more obvious that the formatter will ignore VSCode settings by default if you pick a style guide, since that's what caused the trouble for me. I had no trouble with pipes after I switched my options so that VSCode settings override the style guide.

[domluna]

which style were u using?

[ParadaCarleton]

which style were u using?

Blue.

[MilesCranmer]

Was just about to raise an issue for this. I am seeing the same thing (also with Blue - should it be raised there instead?).

This is very problematic since it can fundamentally change the result of the underlying code. Even more worrisome is that the change will be silent, and only affect the numerical result, rather than give an error.

For example:

using Tullio
x = randn(Float32, 2, 10);
@tullio y[i] := x[i, j] |> sin

The result is:

0.9719883, 0.7482459

But after I run formatter on this, I get:

@tullio y[i] := sin.(x[i, j])

The result of evaluating this is:

1.3280956, 1.6605766

i.e., the formatter moves the operator from outside to inside the sum, resulting in fundamentally different code.

cc @mcabbott

[MilesCranmer]

@ParadaCarleton could you share specifically how you fixed this in your local copy?

[domluna]

you can disable this with pipe_to_function_call=false in the config file. This is set to true when using Blue style

[domluna]

the latest version handles this transform better btw but there are still odd edge cases where it's not semantically equivalent code.

[ParadaCarleton]

the latest version handles this transform better btw but there are still odd edge cases where it's not semantically equivalent code.

In that case, maybe this should be off by default (even when working in Blue style)?

[mcabbott]

I think I said this elsewhere but: |> is a generic function, not syntax. This is valid code:

julia> let |> = atand
         1 |> 1
       end
45.0

Whether anyone exploits this in the wild (for instance to add methods to |> for some type they own) I'm not sure. Is the goal to be semantically correct always, or just not to break too many things normal people write?

That's without mentioning macros. I think quite a few packages give |> special importance within a macro call, for instance here it acts as a "fence" to make xs -> map(x -> x^2, xs)... maybe hard to explain but the macro counts numbers of nested calls and |> does not count:

julia> using Underscores

julia> @_ [1,2,3] |> map(_^2, __) |> println
[1, 4, 9]

julia> @_ println(map(_^2, __)([1,2,3]))  # not sure this is what JuliaFormatter does
#23 (generic function with 1 method)

Looking briefly through the list of other options, always_for_in seems the most likely to alter intended meaning. separate_kwargs_with_semicolon seems more likely to expose bugs in how macros digest input.

[domluna]

these are strong arguments - I would suggest opening an issue https://github.com/invenia/BlueStyle since the formatter style is just an implementation of that. always_for_in can be set to nothing, in which case it will not do anything. although I thought = and in were semantically equivalent? I guess adding your own in or = could change this though right?

separate_kwargs_with_semicolon is false by default but true for blue style.

I guess the best thing to do for now is have a config file like so:

style="blue"
separate_kwargs_with_semicolon=false
always_for_in=nothing
pipe_to_function_call=false

[mcabbott]

I thought = and in were semantically equivalent?

I think they are when inside a for expression:

julia> :(for i in 1:3 end)
:(for i = 1:3
      #= REPL[28]:1 =#
  end)

julia> :(i^2 for i ∈ 1:3 if true)
:((i ^ 2 for i = 1:3 if true))

But outside of that they are different:

julia> i = 2;

julia> i in 1:3
true

julia> :(i ∈ 1:3), :(i in 1:3)
(:(i ∈ 1:3), :(i in 1:3))

julia> let ∈ = atand
         (1 ∈ 1) in [30, 45, 90]
       end
true

julia> let in = atand
         (1 in 1) ∈ [30, 45, 90]
       end
true

julia> in
in (generic function with 38 methods)

julia> ans === ∈  # usual binding
true

[domluna]

it’s only applied in for a for loop so it should be fine then

On Sun, Oct 23, 2022 at 4:25 PM Michael Abbott @.***> wrote:

I thought = and in were semantically equivalent?

I think they are when inside a for expression:

julia> :(for i in 1:3 end)

:(for i = 1:3

  #= REPL[28]:1 =#

end)

julia> :(i^2 for i ∈ 1:3 if true)

:((i ^ 2 for i = 1:3 if true))

But outside of that they are different:

julia> i = 2;

julia> i in 1:3

true

julia> :(i ∈ 1:3), :(i in 1:3)

(:(i ∈ 1:3), :(i in 1:3))

julia> let ∈ = atand

     (1 ∈ 1) in [30, 45, 90]

   end

true

— Reply to this email directly, view it on GitHub https://github.com/domluna/JuliaFormatter.jl/issues/439#issuecomment-1288193834, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAORUF23A2IC5YCFCHOLXOTWEWNLNANCNFSM5AHBVP2A . You are receiving this because you commented.Message ID: @.***>