polovy
List append (++) does not return a list
I am going through some tutorials, and one of the tasks is to create a list of items by taking first two elements of the existing item and appending them to the end of said list. The problem I have is that for some numerical values in the list, I get a strange response returned.
The Cos:
defmodule Tutorial do
def mirror_row(row) do
[first, second | _tail] = row
row ++ [second, first]
end
end
the results I get are:
iex> Maps.mirror_row([1, 2, 3])
[1, 2, 3, 2, 1]
iex> Maps.mirror_row([121, 12, 123])
~c"y\f{\fy"
The 1st result is as expected, but the 2nd I would expect [121, 12, 123, 12, 121].
What is actually happening here and why?
I chacked this for different values and it does not make sense to me.
Some other results:
iex> Maps.mirror_row([123, 122, 121])
~c"{zyz{"
iex> Maps.mirror_row([123, 22, 12])
[123, 22, 12, 22, 123]
iex> Maps.mirror_row([121, 122, 123])
~c"yz{zy"
iex> Maps.mirror_row([121, 12, 123])
~c"y\f{\fy"
iex> Maps.mirror_row([121, 12, 13])
~c"y\f\r\fy"
iex> Maps.mirror_row([121, 22, 13])
[121, 22, 13, 22, 121]
Thanks.
Most Liked
dimitarvp
IEx.configure(inspect: [charlists: :as_lists])
Run this manually inside iex or put it in a file called .iex.exs at the root of your project and it will be ran automatically on iex startup in that directory.
LostKobrakai
What you’re seeing are charlists using the ~c sigil. They are the exact data you expected, but printed as text to allow interoperability with erlang, which uses charlists as their default string type: List — Elixir v1.17.3
JEG2
The folks calling Erlang functions that return “strings” that wouldn’t be readable.
I provide a detailed breakdown of the reasoning behind this feature and how to alter the behavior in Livebookisms. Here’s an exert:
sbuttgereit
As an aside, I completely forgot this was out here…
Which, naturally, includes this very issue. I’m guessing this post is not very visible and only appears in searches… which in a case like this is more likely to not appear in a search since you’d kinda got to know what the issue was in the first place to hit the right search terms for it.
It’s a good idea… but I wonder if there’s a way to call this out for special attention so that it isn’t forgettable for those that might add to it or discoverable for those that might need it.
LostKobrakai
I’d not just iex. The inspect protocol is used in all manner ot places to turn arbitrary data into a string representation. That includes logs, tracing, error handling system and yes you iex shell. I would consider those very much important for production usage. And no I don’t want to need to transform a list of integersin my error tracking to a string to be able to figure out what the error is about.
I also don’t consider changing a subset of those places to different defaults. That would be even more confusing.
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
We build reliable cloud platforms for business-critical systems.
Categories:
Sub Categories:
Forums
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Practical resources that improve the lives of professional developers.
Develop your skills with books, videos, and courses.
The deployment platform built for Elixir: PaaS ease, VPS control.
Courses that'll move you from confusion to "Aha, now I get it!"