I love that proposal, I’ve raised this as one of my points here and I think it will solve the problem of two ways of expressing strings.
I think it will, but there are a few other things we need to keep in mind.
I think that compiler shouldn’t raise more than one warning for dependencies
We need to do something about string() type (maybe warn too?)
We need to create a crawler which will translate old elixir codebases to use sigils instead of charlists
I think that printing ~c"" version is the best decision, because it won’t break any software which was used to grep logs or errors, but it’ll give an idea that '' is deprecated
It seems very weird to me to optimise any aspect of a language for the first hour or day of learning. I’m as poor a programmer as exists anywhere (possibly the only long-term unemployed developer in the contemporary world!), am not that distant from the time when I first came across Elixir (ie. I remember what starting with it was like), and can say with 100% certainty that there’s no way the '/" distinction could have caused more than a 1 minute confusion.
I’m indifferent, despite having to explain charlists to newcomers several times.
I saw some proposal somewhere (can’t remember) of deprecating/removing charlists from Erlang/Beam entirely… I understand why that’s not feasible, but… one can dream…
Well … in that way we could remove all syntax sugar in Elixir.
Example question:
Why {:ok, number} becomes map [ok: number]?
defmodule Example do
def sample(number), do: {:ok, number + number}
end
iex> for number <- 1..10, do: > Example.sample(number)
[ok: 2, ok: 4, ok: 6, ok: 8, ok: 10, ok: 12, ok: 14, ok: 16, ok: 18, ok: 20]
and someone may say we should print every keyword like a normal list [{:key, value}, …] as printed result may be confusing for newbies.
The key point here is to keep as much as we can and try to not confuse. There would be always some difference with other languages and there would always be some features newbies does not know about.
One time someone tries to force me to write code without pipes as new developers does not know how pipe works. Instead he used a nested, nested, nested … case/cond/if and code he describes as “easy to read” had something like 13 indention levels in one line …
I’d expect this to be a useful change. Raising the signal of differenciating binaries from charlists should be a net positive. Though I’m not sure about the use of double quotes as the sigil delimiters. They might be more confusing to people unaware of charlists, but I’d probably prefer them as someone aware of them.
I don’t think we can get rid of the need of being aware of charlists and what they are/how they work. So the best we can do is make people aware of them earlier, rather than later, at dev/built time, rather than in production. This change would support that.
I’d argue both are equally confusing. But I don’t think they’re equal in helping people to resolve that confusion.
To someone unaware of charlists and the fact that single quote are not interchangable with double quotes in elixir 'abc' doesn’t hold any signal of “this is something you don’t know about yet”. At best they wonder why there’s single quotes suddenly, but from my experience that doesn’t help much without knowing the significance of that. ~c"abc" on the other hand does hold more signal, even if the person might still wonder why there’s a sigil in front of the “string”. It hopefully leads them to learning about sigils (if unknown before) and sigil_c docs will lead them to learn about charlists.
Having provided explanations to many on slack as well as having tried to improve the documentation of charlists a few years ago I still feel like the most difficult part of explaining charlists is the fact that formatting a charlists as text is only a matter of representation of a list of integers, but it doesn’t mean it’s not a list of integers anymore. Using sigils hopefully makes this less mind bending, given other sigils are also used to represent a certain value via a different representation of it. ~D[2022-08-10] is a textual representation of a date struct, ~r/\d*/ defines a regex struct via its text format, …. At best people might have been in contact with sigils before, but given how many code challenges/katas/… accidentally produce charlists this is certainly nothing to rely on.
formatting a charlists as text is only a matter of representation…
I agree and was coming to make the same point. In my experience helping newcomers, the confusion stems from people assuming that 'abc' is a string - because it would be in other languages and it’s a reasonable assumption.
If it becomes ~c"abc" it’s now clear that we are not talking about a string which should help remove the confusion and prompt them to look up the ~c sigil.
There is definite value in being able to see both representations (the numbers in the list OR the characters they refer to) but usually when we write charlists we think in letters, ie we write 'abc' and not [97, 98, 99].
So I think [97, 98, 99] should be printed as [97, 98, 99], but if you write the sigil it’s printed as ~c"abc".
Big plus one on the proposal and +1 for printing as ~c"abc" from me.
Great idea. Not only this gives more signal about what is happening, but also it simplifies the language by reusing an existing thing (sigil) in place of a separate one (single quote) in an intuitive way.
Nitpick: the printed form should be ~C"chars" since ~c"foo #{bar}" will try to interpolate bar
Having answered a fair number of these, I don’t think anything short of a one-time message from IEx, “Hey, I just printed that thing that looked like a charlist as a charlist. Read this doc if that wasn’t what you wanted” would solve the problem. ~C is a tiny bit more google-able but not by much, and “I entered ~C(hi there) but IEx thinks it’s ~C"hi there" halp” posts could appear.
Yes and no. I helped people learn Elixir off-forum and while iex printing ~D[2020-07-10] does tell them that this is something special they have to look into, on the other side of the coin iex does not make it easy to search for sigil’s docs or understand what a sigil even is.
Try typing e.g. h ~S in iex – you get an error. You have to know what you are looking for in the first place and type h sigil_S which IMO kind of defeats the purpose of having something that can guide the learner without them having to go to a website [to learn about sigils].
I propose this be expanded to 3 action points:
Print charlists as integer lists by default in iex
Do use the new canonical form of ~c"something"
Change iex and/or the h helper so that it can understand queries like h ~c
Having all three would IMO allow people to self-onboard. They type ‘abc’ in iex and see ~c"abc" and then intuitively they would do h ~c and would get an explanation. Of course that assumes they know about iex and h in the first place, sure but hey, we have to start somewhere.
