Proposal: two- or three-letter sigils

[w.m.w...@student.rug.nl]

Sigils are a great way to create a shorthand function that takes an (optionally interpolated) string as input, and returns some kind of useful data structure.

Because there are only 26 letters in the alphabet (out of which  c, r, s and w are already taken), I think that conflicts between different sigils using the same letter will increase. Of course it is a possibility to alias or wrap certain sigils as other sigils using a different letter, but this greatly increases source code complexity. Of course, another option would be to always use a long-hand alternative to the sigil (which should be available in a module, although this is not enforced by Elixir), but this does net let you use the conciseness of the sigil.

 

I believe that a better solution would be to allow two- and three-letter sigil names. This would both reduce conflicts as well as allow sigil names that are easier to recognize and remember.

Say I want to create a sigil that transforms multiple colour representations into hex format (or maybe another format like HSL depending on the supplied options). I cannot(should not) use `~c{}` because that's used by Elixir itself to build char lists. Using `~col{}` would make the sigil more or less self-documenting. (with 'more or less' I mean that if you see it used in practice, e.g. `~col{red}` or `~col{light green}` you'll understand it. And after you know once what the `col` sigil identifier means, it is probably easier to recall it later than if it were just a single letter.)

Another example: If I want to create a sigil that converts a Roman Numeral to an integer. The use of `~r{}` is also already defined by Elixir. But what else to call it? `~rn{}` would be a logical choice.

Is this a reasonable idea? Or are there problems I did not think of?

[Onorio Catenacci]

I can't see a problem with it but I also don't foresee a lot of use cases for it.  The use cases you propose seem somewhat contrived. To quote the old cliche, it sounds like a solution in search of a problem. 

If I needed to convert a named color to a hex code, I'd simply build a small, simple function to do so:

def col(colname="red") when is_binary(colname), do: 0x0000000 #I don't know the hex code for red :)

def col(colname="light green") when is_binary(colname), do: 0x000000 #Nor for light green either :)

etc. 

I'd be more likely to call this col_to_hex or something more descriptive of its function but I'm trying to stick with the 

convention you used above.

I mean I can see where a sigil could save some work here but I'm not sure there are truly enough use cases to justify the change.  Are there other, more significant use cases I'm unaware of?

--

Onorio

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/50f05dd3-b593-4f63-84b7-d6b16e1eaa8f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Onorio Catenacci
 
http://onor.io

http://www.google.com/+OnorioCatenacci

[José Valim]

It is something that came to mind a couple times.

My concern with allowing more sigils is because sigils are not something we necessarily want to advocate. Creating functions names with just one letter is something that we would rarely do and that's basically what sigils are.

That said, the reason sigils exist is because they disable escaping rules which is very useful for char lists, strings, regular expressions. If the goal is to create colors, something like color(:red) or color(:light_green) is likely a better fit.

José Valim

www.plataformatec.com.br

Skype: jv.ptec

Founder and Director of R&D

--

[w.m.w...@student.rug.nl]

Sigils have the following special properties:

• They allow very concise definitions that in some cases might be more readable than the long-hand alternative.
• This concise definitions with rich behaviour is further enhanced by the option to pass single-letter modifiers to a sigil.
• They allow developers to circumvent normal string escaping rules, which in some cases is extremely useful.

I completely agree with ou, José, that there are many places in which sigils are not the solution to a given problem. Color-parsing is something that indeed is probably better handled by a `colors` function. (I chose it as an example as defining a color sigil is actually used as an exercise in David Thomas' "Programming Elixir" book).

However, there are also enough cases in which sigils do seem to be a very elegant solution. I am mostly thinking about things whose input syntax is more dynamic than simple pattern-matching allows, and whose syntax might be hampered by string-escaping rules. Some things that fall in this category:

• Regular Expressions (which of course already use sigils)
  
• executing shell-instructions (similar to Ruby's backtick-syntax)
• Natural Language Processing
• parsing propositional logic
• interpreters for other kinds of (domain specific) languages and syntaxes.
• Et cetera. You can probably think of some I don't know of.

I believe that these cases are common enough to justify and require an increased amount of sigil-possibilities.