Sigils are (not only) macros

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:

1. You would overcomplicate work of LSP / tools maintainers
2. You would require breaking changes in Elixir core which would not happen before version 2.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!