No they are not (not necessarily, at least.)
Well … and that’s exactly what happens when you try to write short messages and don’t want to go too off-topic. There is always someone who would catch just one tiny part that was not explained properly.
Yes, they can be functions and macros as well. Sigils are not even a data type in Elixir
, but exactly a function that return some data. They can return different types depending on flags etc., etc. The true value of sigils is not that they change a string into some data because therefore as you said it could be replaced with a “normal” parse-like function.
It’s more like a way to represent a custom struct data in a short format that could even have it’s own syntax highlight. This can’t be replaced with a “regular” strings and any functions unless some library would claim that they reserve some specific naming. This only adds more work for the developers.of LSP
and other tools, so there is really no acceptable replacement here as far as I know.
This was not a nitpicking, in the first place. Messages on forums are public domain and people tend to memoize slogans, therefore I felt kinda obliged to help not so experienced devs reading this not to memoize the plain wrong statement.
The true value of sigils is not that they change a string into some data because therefore as you said it could be replaced with a “normal” parse-like function.
Why is that? The sigil is the syntactic sugar for a function call under the hood. One might use Kernel.sigil_r("0-9", [])
everywhere instead of ~r/0-9/
and literally nothing would have changed for them.
This can’t be replaced with a “regular” strings and any functions unless some library would claim that they reserve some specific naming.
Sure it can.
This only adds more work for the developers.of
LSP
and other tools […]
What “this”? The parser is a rather dumb thing, it pays no dime to whether it should highlight the string inside some fancy brackets or inside sigil_r("
and the closing "
.
and that’s exactly why people here say I go often off-topic
That’s not true
iex> quote do
~r/0-9/
end
{:sigil_r, [delimiter: "/", context: Elixir, imports: [{2, Kernel}]],
[{:<<>>, [], ["0-9"]}, []]}
iex> quote do
Kernel.sigil_r("0-9", [])
end
{{:., [], [{:__aliases__, [alias: false], [:Kernel]}, :sigil_r]}, [], ["Elixir", []]}
Pattern matching the AST
looks completely different. In first case you pattern-match by sigil
name. In second case you pattern-match on the call. Let’s see it in practice:
ast = quote do
~r/0-9/
end
case ast do
# simple and clear
{:sigil_r, sigil_meta, [input_ast, flags]} when is_list(flags) ->
# optionally sigil_meta can be validated
{:sigil_r, sigil_meta, [highlight(input_ast, :regex, flags), flags]}
# …
end
now same for a call:
ast = quote do
Kernel.sigil_r("0-9", [])
end
case ast do
# overcomplicated
{{:., dot_meta, [ast_alias, :sigil_r]}, call_meta, [string, flags]} when is_list(flags) ->
result = maybe_highligh(string, :regex, flags, ast_alias)
{{:., dot_meta, [ast_alias, :sigil_r]}, call_meta, [result, flags]}
# …
end
defp maybe_highlight(string, :regex, flags, ast_alias) do
if Macro.expand(ast, __ENV__) == Kernel do
highlight(string, :regex, flags)
else
string
end
end
So if you would look for unifying them into regular functions then:
- You would overcomplicate work of
LSP
/ tools maintainers - You would require breaking changes in
Elixir
core which would not happen before version2.0.0
I have no idea if custom highlights for sigils support “regular” sigil call and I’m not sure if anyone really care about it. Also look that I use input_ast
and string
in each case as they are completely different. For you it all looks simple, but somehow needs to make it work under the hood.
The parser indeed is, but the parser is not everything. You don’t highligh whole .ex
and .exs
file with html
parser just because it can contain HTML
code in some sigil, right? Think that you call a highlight
code for every string
you find in AST
. That’s obvious waste of resources.
Also as said sigils can be macros. With macros we work on compile-time and that’s completely different thing that a simply function call.
Again, this goes off-topic. Sigils are not related at all to the original topic and also not to my proposal which is just one of many possible solutions for readability and LSP
integrations.
You can hash it out here, but let’s please keep that convo on topic!