# Is it possible to create different operator for the dot-call syntax?

The dot-call is such a great feature of Julia. But it strangely use the same operator as field value accessor. The f.() syntax looks strange and the dot symbol is not consistent as the dot production symbol in math books.

For example:
X .= f.(2 .* X.^2 .+ 6 .* X.^3 .- sqrt.(X))

If the above code could be written in following forms, it will be less strange to me.
@elementwise X = f(2X^2 + 6X^3 - sqrt(X))
X ·= f·(2 ·* X·^2 ·+ 6 ·* X·^3 ·- sqrt·(X))
The · symbol in the second form might be hard to type, but it has a lot chance to be solved by text editors in future. So that’s why come the question in the title.

You can use `@. X = f(2X^2 + 6X^3 - sqrt(X))`.

It’s not possible to use something different from `.` (without significantly changing the language).

3 Likes

The center dot `/cdot` is already defined and means dot product between vectors

1 Like

There has been a long discussion about the dot-call syntax and its inconsistency with the dot operators:

`a .+ b` vs. `+.(a,b)`

The dot is placed before operators while it’s placed in between the function name and the parentheses.
Placing the dot in front of the function name would eliminate the difficulty to distinguish dot called functions from field access.

AFAIK it was decided to keep the current syntax.

References: #8450 (#20249, #22501)

1 Like

@shorty66 Thanks for the reference. From the discussion, it seems the current syntax was already a careful design decision between several options.
But I didn’t found the discussion about the @. macro. I think give a literal intuitive name for dot-call macro would be a good complement for the original form. I assume the macro format could be supported without much technical difficulty though.
E.g.
@elementwise X = f(2X^2 + 6X^3 - sqrt(X)) or
@dotcall X = f(2X^2 + 6X^3 - sqrt(X))

I like `@elementwise` as an alias to `@.`

I think `@.` has been chosen as it’s meant for users who already know the `dot`-syntax and only want a more convenient form.
Reading code which uses `@.` might prove a little difficult to new users who do not know about the `dot`-syntax (especially as the search for `@.` in the julia docs isn’t too helpful)

For discussion about `@.` see https://github.com/JuliaLang/julia/pull/20321 where it was implemented. `@.` is just convenience for `@__dot__` so you could use that if you like that better.

1 Like

`@.` expresses the dot-call by visual form;
`@__dot__` expresses the dot-call by sound;
`@elementwise` expresses the dot-call by operation logic, which makes more sense to me when I am reading the code.

1 Like

I am not sure I understand the above sentence.

In any case, these discussions about surface syntax quickly reach the point that comparisons between various solutions become very subjective. Given this, the best solution is to just pick one of them, stick to it, and don’t change it unless there is a compelling reason, and then try to tie the change to a related redesign that would bring in changes anyway. This is what happened to `@.`: there were very long discussions, a decision was reached, and now people can move on and use it. At this point, suggestions for changes will unlikely to get a lot of traction.

Try using Julia as is for a while, and see if you get used to it. If you want to contribute to its design, there are many areas that could benefit from insight and experimentation, but usually they go much deeper than surface syntax.

3 Likes

This seems to be a discoverability issue rather than a naming issue per se. We should try to make sure that the dot syntax is discoverable when one searches for the words “elementwise” and “vectorized”.

3 Likes

@Tamas_Papp
`@__dot__ expresses the dot-call by sound;`
. pronounces “dot” in general context, either in Julia or not. That’s what I meant.

`these discussions about surface syntax quickly reach the point that comparisons between various solutions become very subjective.`
That’s why I discussed the macro syntax only instead of the general dot-call operators. It is still subjective but should be more focused.