list mapping - strange behaviour

[nifle]

In the  Dave Thomas book there's an example of defining a map-function:

(extracted:)

  def map([], _func), do: []
  def map([ head | tail ], func), do: [ func.(head) | map(tail, func) ]

Look at these runs: Why do the runs marked 'NB' produce so strange results?
(Erlang 18.1, Elixir 1,1)

iex(9)> MyList.map [5,6,7,8], &(&1*&1) 
[25, 36, 49, 64]

iex(10)> MyList.map [5,6,7,8], &(&1*&1)
[25, 36, 49, 64]

iex(11)> MyList.map [6,7,8], &(&1*&1)  NB
'$1@'

iex(12)> MyList.map [7,8,9], &(&1*&1)  NB
'1@Q'

iex(13)> MyList.map [17,18,19], &(&1*&1)
[289, 324, 361]

iex(14)> MyList.map [8,9,10], &(&1*&1)   NB
'@Qd'

iex(15)> MyList.map [9,10,11], &(&1*&1)  NB
'Qdy'

iex(16)> MyList.map [9,10,12], &(&1*&1)
[81, 100, 144]

iex(25)> MyList.map [6,7,8,12], &(&1*&1)
[36, 49, 64, 144]

Grateful for suggestions!

[Constantin Rack]

The results are interpreted as a char list:
http://elixir-lang.org/getting-started/binaries-strings-and-char-lists.html#char-lists

If all elements of a list can be interpreted as ASCII chars, they are printed as chars, otherwise as normal list (last example):

iex(1)> [65,66,67]
'ABC'
iex(2)> [65,66,67,10]
'ABC\n'
iex(3)> [65,66,67,10,0]
[65, 66, 67, 10, 0]

- Constantin

[Onorio Catenacci]

I know this isn't the place to propose it but maybe in some future version of the IEX we can have it always display lists as lists even if the values fall within ASCII char ranges and add a switch to enable the current behavior for those who want it.  This little nicety (displaying values as ASCII chars I mean) seems to cause a lot of confusion to new folks without adding a significant benefit.

[José Valim]

I know this isn't the place to propose it but maybe in some future version of the IEX we can have it always display lists as lists even if the values fall within ASCII char ranges and add a switch to enable the current behavior for those who want it.  This little nicety (displaying values as ASCII chars I mean) seems to cause a lot of confusion to new folks without adding a significant benefit.

We have already discussed this a couple times.

1. IEx can already be configured with: IEx.configure inspect: [char_lists: false]

It is documented and it can be set with ~/.iex.exs

2. "without adding a significant benefit" - it adds a large benefit whenever you are interfacing with Erlang code as the error messages will be in char lists. A lot of us rely on this feature heavily, we just don't notice because it is there.

[Onorio Catenacci]

Thanks Jose.  

I wasn't aware of prior discussions or the ability to set the default the other way on Iex.  And that's an excellent point about Erlang error messages which I hadn't given any thought to.  Thanks for taking the time to shed some light on the decision. 

--

Onorio

[Onorio Catenacci]

By the way, seriously, thanks for taking the time to explain this.  

I was under a very mistaken impression that the whole thing about displaying values in the ASCII range as characters was just a heuristic that someone hadn't thought through completely.  When you explain the real reason it's there, it makes much better sense.  In fact if I can find a few free minutes I may blog this because this is the first time I've heard of the use case for this behavior and I don't think I'm the only one that was in the dark about this.  At least I hope I'm not. 

--

Onorio

On Wednesday, October 28, 2015 at 12:38:24 PM UTC-4, José Valim wrote:

[Greg Vaughn]

I agree. I had also missed a reference to IEx.configure before. I do wonder if the default should be `char_lists: false` though. That would streamline things for newbies, but more advanced people interfacing with erlang would then need to reverse the default in their .iex.exs.

Tough call.

-Greg Vaughn

> --
> You received this message because you are subscribed to the Google Groups "elixir-lang-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-ta...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/6505439c-9036-4117-afbe-36c9c18885a6%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Booker Bense]

I wonder if there is any way we can look in the binding here

 {result, binding, env, scope} =

      :elixir.eval_forms(forms, state.binding, state.env, state.scope)

    unless result == IEx.dont_display_result, do: io_inspect(result)

and make io_inspect smarter. Or maybe we could make printable? smarter and 

have it look for a common word or substring? Do all erlang error messages have

some kind of flag? 

- Booker C. Bense 

[Booker Bense]

Some quick questions, 

In the many, many times we have seen and answered this question. 

Is the list ever longer than 5? 

Does it ever have all letters? 

While there is no solution that will "fix" this for all cases, I think we can drastically reduce the number

of times it happens while still keeping the existing behaviour for interacting with erlang libraries. 

If you want to see the effect of 

IEx.configure inspect: [char_lists: false] 

try this. 

iex> :application.info

iex> IEx.configure inspect: [char_lists: false] 

iex> :application.info

- Booker C. Bense

[Edward Stembler]

2. "without adding a significant benefit" - it adds a large benefit whenever you are interfacing with Erlang code as the error messages will be in char lists. A lot of us rely on this feature heavily, we just don't notice because it is there.

I wonder though, if there's a way to only enforce Erlang style list output only when dealing with Erlang messages, or where Erlang expects it?  As others have mentioned, this seems to be an issue for newcomers, and possibly a slight barrier of entry.  I feel strongly in supporting the Principle of least astonishment.  We are humans after all, write code to be read by other humans.

Just a thought.

[Phani Mahesh]

The trouble is that erlang messages are not special in any way. This decision is due to how charlists in erlang are designed, they literally are just lists of numbers. And there is no way to distinguish a charlist from a list of printable numbers.

People will end up using something from erlang sooner than later, so I believe it is best if they encounter this as soon as they can. Principle of least astonishment also implies consistency. Since we do not have a better heuristic, trying to do anything that only works for some specific usecases causes more astonishment (confusion) IMO.

To change this requires changing erlang itself, which is not possible. The best way to handle this may be to explain why this happens in tutorials upfront. Newcomers are often capable of more than we give them credit for.

--

You received this message because you are subscribed to the Google Groups "elixir-lang-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-ta...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/62132ff8-ddec-4db1-8bb5-d7a5148e643c%40googlegroups.com.

[Edward Stembler]

Thanks for the explanation.  Also, good points!

[Onorio Catenacci]

I think you're right Phani. I think we just need to say something in the tutorials about how this works and why it works the way it does--and when the question comes up from new Elixirists we point them to the tutorial. I mean until Jose explained it to me yesterday I thought the behavior was intended to be some sort of convenience feature. I didn't realize there was such a good reason for the behavior.

--

Onorio

On Thursday, October 29, 2015 at 11:05:32 AM UTC-4, Phani Mahesh wrote:

[Alexei Sholik]

The Getting Started guide mentions this http://elixir-lang.org/getting-started/basic-types.html#linked-lists

--

You received this message because you are subscribed to the Google Groups "elixir-lang-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-ta...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/b33a0cda-435e-4632-af8b-b1d2aa56d56a%40googlegroups.com.

[Onorio Catenacci]

Hi Alexei,

That's an excellent point.  I may have read that at some point because I've never been confused by the fact that some lists show characters when they're evaluated.  Or I may have run across that in Dave Thomas' book.  I can't remember in which place I first saw that but, as I say, the behavior never really surprised me.

Either way, I guess the spark just didn't jump across the synapse that would have enabled me to realize the "why" of displaying characters rather than numbers.  As I say, until Jose explained the excellent reason for this behavior the other day I just thought it was a little bit of syntactic sugar to ease working with binaries.

--

Onorio