consider the example where I came across this. I needed 8 char fixed hex
representation of a given integer, so for input 16, output should be
"00000010". This is my basic version for that
defp to_fix8_hex(num) do
"0x" <> num_hex = inspect(num, base: :hex)
rem = 8 - byte_size(num_hex)
prefix = 1..rem |> Enum.map(fn _ -> "0" end) |> Enum.join("")
prefix <> num_hex
end
The above doesn't work, when rem becomes 0. From my background in C style
for loop, where increments or decrements are explicit, the loop itearation
doesn't happen, when start and end constraints are beyond limit. here the
confusion happens, because I'm expecting 1..rem to always count forward and
whenever rem becomes less than 1, the counting should stop. The present ..
behaviour is that it automatically changes direction from counting forward
to counting reverse depending on the start and end values. This is not a
problem when constants are used, like 1..10000 or 10000..1 where intent is
very clear and never confusing. The confusion comes when one of the (either
start or end) limit is variable.
The solution in this case was to treat rem < 1, as separate case and all
was fine. Just that it took me some time to figure that out because I was
used in writing this kind of logic in C in a particular way.
I see your point of iterators being lazy and why Enum.reverse will not meet
the requirement. So probably a different syntax for decrements? But unless
the confusion is common enough, I don't see any point in changing the
present behavior.
thanks
miwee
On Sunday, December 25, 2016 at 4:26:09 PM UTC+5:30, Eric Meadows-Jönsson
wrote:
>
> Personally I like the behaviour of ranges when the end of range is smaller
> than the first. Can you elaborate on why it's confusing?
>
> The problem with Enum.reverse is that it returns a list instead of a range
> so Enum.reverse(1..1000000) would return a list allocated with a million
> elements.
>
> You are correct that it would be a backwards incompatible change so if we
> do decide to change it it can only be finalized in Elixir 2.0.
>
> On Sun, Dec 25, 2016 at 11:28 AM, miwee <[email protected] <javascript:>>
> wrote:
>
>> TLDR: it's a nit picking and may introduce breaking changes without
>> possibly any significant gain, except conceptual clarity and explicitness.
>>
>> iex(27)> n = 4
>> 4
>> iex(28)> 1..n |> Enum.into([])
>> [1, 2, 3, 4]
>> iex(29)> n = 1
>> 1
>> iex(30)> 1..n |> Enum.into([])
>> [1]
>> iex(31)> n = 0
>> 0
>> iex(32)> 1..n |> Enum.into([])
>> [1, 0]
>>
>> The result for n = 0, is little bit magical, as I was expecting it to
>> return [], but instead it auto-magically detected that end is less than
>> start and hence it counted decrementally. I think it creates confusion,
>> particularly when both start and end are not constants like the above case
>> given.
>>
>> So does it make sense to restrict the behavior of .. operator to always
>> count incrementally. For the case of decremental counting Enum.reverse can
>> be used. In that sense 1..4 |> Enum.reverse() is identical to present
>> behaviour of 4..1
>>
>> --
>> 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 [email protected] <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/elixir-lang-core/da1cd897-1410-4237-b95f-04e61ec7bcfe%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/elixir-lang-core/da1cd897-1410-4237-b95f-04e61ec7bcfe%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Eric Meadows-Jönsson
>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/1384d860-7250-4d2a-864c-90d93d88e0ed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.