Yes, I misread that as a specific part of the page.
tmbb
NobbZ
It is a special form, like %{}. It is not directly part of the syntax, but treated in a bit special way. Kind of a hardcoded macro, internally working pretty much like a sigil, but not exactly as them.
0
tmbb
You (the elixir community in general, not you specifically) seem to use the word syntax in a way I’ve never seen it used… What you’re saying is akin to: “This is not syntax - It’s just transformed by the compiler into an AST in which the root is a macro that can’t be redefined by the user”. Isn’t that what syntax is? The rules used for the compiler to transform text into an AST?
0
michalmuskala
The syntax, for me, is exclusively what is handled in the parser. Anything beyond that is not “syntax” but “language features”. How binaries work has no special treatment in the parser, so to me, it’s a language feature that uses regular Elixir syntax.
0
tmbb
Yes, but who turns <<a, b, c>> into: {:<<>>, [], [{:a, [], Elixir}, {:b, [], Elixir}, {:c, [], Elixir}]}? Isn’t it the parser? (I assume it is, even though I have no idea how Elixir parses Elixir).
This is not the same as turning: def d(x), do: x into:
{:def, [context: Elixir, import: Kernel],
[{:f, [context: Elixir], [{:x, [], Elixir}]}, [do: {:x, [], Elixir}]]}
The parser seems to use different rules in each case: in the def case, the parser just expands function calls into AST nodes according to what you call the “syntax” of the language. In the <<>> case, the parser uses some rules (different from just expanding function calls) and turns it into: {:<<>>, [], [{:a, [], Elixir}, {:b, [], Elixir}, {:c, [], Elixir}]}.
Those rules are the syntax.
Of course the parser doesn’t know that <<>> is a binary, it’s not it’s job. Iterpreting the AST generated by the parser is semantic analysis or something like that. The parser doesn’t even know that the :<<>> atom is non rebindable. But it does know that when it finds <<...>> it must output the AST [{:<<>>, [], [...]}].
0
tmbb
It’s very cool! Just tried to quote some <<>> expression and the minus operators expand into actual minus operators inside the AST. I still contend that <<>> looks a lot like syntax (see above)
0
josevalim
Creator of Elixir
Sigils are very different from containers such as tuples, lists and binaries.
Yes. But the parser does not add meaning to this. You can also write this:
iex(1)> quote do: <<x :: def(foo, do: 1)>>
{:<<>>, [],
[{:::, [],
[{:x, [], Elixir},
{:def, [context: Elixir, import: Kernel],
[{:foo, [context: Elixir], Elixir}, [do: 1]]}]}]}
Therefore, syntax wise, <<>> can mean anything. That’s why I said you won’t find the documentation for what <<1::byte>> means in the syntax reference. The syntax allows you to put whatever you want on the right side of ::, the meaning comes from elsewhere.
This is a big contrast to other languages, such as Erlang, where what is allowed inside <<>> is a directly known by the parser.
1
rvirding
Creator of Erlang
I would say that that is a language developers way of looking at it. 
For most users of Elixir whether parts of the “standard syntax” like def and if are built-in syntax or macros is completely irrelevant. How I write them and how do I use them are the important bits. do ... end vs do: ... is a little more complex but I think you can happily just describe what they look like and how they equate to make most users happy and to get them right.
Again, I think most users, even those who write big complex systems, will not define their own macros even though they will be using lots of things defined by macros. In one way it is similar to the fact that using OTP you can write large extremely concurrent and parallel systems without a spawn, send or receive in sight. You should know that things are being done concurrently but you don’t need to use the explicit concurrency primitives.
0
tmbb
Ok, thanks! I agree with you, then. The types inside the <<>> are certainly not syntax, and they shouldn’t be highlighted any differently in a syntax highlighter.
0
rvirding
Creator of Erlang
I agree. What a binary looks like is very much syntax, the same as for all the other data types. The syntax describes what things look like. What they are parsed to is basically irrelevant to most users.
I think the important thing is to understand for whom you are writing a syntax description.
1