I did such an optimization in my library, but interestingly there was no
improvement in performance and compiled size. I am guessing the compiler does a
better job by default than my optimizations. :-P i believe the optimizations
are still in the version history of codepagex
--
You received th
Actually this was thoroughly discussed when lhs rhs was sertled upon. so the
current naming was not chosen by accudent, and at the time found the superior
option.
I still personally think lhs and rhs is fine, and being shown in the terminal,
also quite a few characters less. This may prevent w
I wouldnt emit a warning here as adding commas should be perfectly valid. How
would we deal with the use case where you wanted to include the commas?
--
You received this message because you are subscribed to the Google Groups
"elixir-lang-core" group.
To unsubscribe from this group and stop re
You have my vote.
Never used single tick lists much, and they were confusing to me, much due
to baggage from Ruby/Perl where they are all strings. Making the syntax
more explicit makes sense.
Tallak
--
You received this message because you are subscribed to the Google Groups
"elixir-lang-cor
Hi!
I guess I might make a stab at analyzing this.
The code will create a list of the short sequences of length k that occur
more than `t` times inside one of the longer sequences of length `l`. The
order of these sequences is i undefined.
What I read from Jose's reply was that the use of Flo
I assume you mean the default function should be
'''
fn x -> !x end
'''
To reject any falsey value. It does seem reasonable, but I dont think it is
nearly as readable as 'compact', so I vote nay to this one...
In fact, isn't this a better option? (Or equally good)
'''
def filter(enum, fun \\ f
I had the same thought some time ago, with a code to prove the possibility.
I have since decided it's a bad idea.
There are many ways to extend Elixir 'irresponsbly' making code that is not
clear and readable like core Elixir is. So by adding features like extended
pipes and iteratable tuples
I believe it would be useful to not sort if there are very many keys as well. A
huge map would presumably be inspected in a short while, skipping keys after
the first few. Inspecting a huge map could become cpu/memory intensive, which I
would find surprising... anyways +1 from me
--
You recei
th cpu and memory to vuild sorted structure, and later would
>>>> spend more cpu on its garbage collection. I don't like the idea of losing
>>>> production performance only for development convenience.
>>>>
>>>> On 16 February 2017 07:25:51 GMT+1
stream_split would do something like that. The tail is stored in a continuation
function, so i'm not sure if this is 'good code', and i'd not vouch for putting
something like that in stdlib without a thorough analysis (eg covering issues
related to cleaning up the enumerable if the tail is not i
Here's one way of solving this with macros:
https://gist.github.com/tallakt/a6701b1e5c2808c85104
You don't need to modify the pipe operator.. keep it simple.
And, please dont use my gist, just use `conn = ...`
:)
--
You received this message because you are subscribed to the Google Groups
"
I dont like it. Its too flexible. I believe the code becomes unwieldy as you
can mix s lot of different stuff into the ctrl block.
I believe this construct may promote complex code.
Why do we need this? Elixir has excellent patten matching support that is
lightyears ahead of the C class of la
Ok. Now I understand more.
I believe the use of '|' is new?
Tallak
--
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-core+unsubscr...@googlegrou
Hi. I think its a fine suggestion, and i agree that its more descriptiive than
the alternatives. Even so, the amount of use it would see would perhaps not be
so big that we could not equally well get by with using replace. Keeping the
stdlib consise is a quite major issue, so I'd have to agree o
https://hexdocs.pm/elixir/Map.html#get_and_update!/3
--
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-core+unsubscr...@googlegroups.com.
To view t
I agree the function is missing. The name shoul be different than your
suggestion, maybe ‘update_existing(...)’?
Still the alternatives, though not as efficient perhaps, should give not big
practical problems. So adding this might be considered margin
Perhaps even the get_and_update is the most
I would say no to this one. I think using < is ok. No change necessary.
Elixir isnt statically typed, so at least for me, in general, i dont bother
with is_number
--
You received this message because you are subscribed to the Google Groups
"elixir-lang-core" group.
To unsubscribe from this gr
I am still not convinced. Elixir is not a statically typed language. The guard
you mention does add some checking, and I wouldnt mind seeing it in Elixir
code, but there are so many of these kinds of bugs that still remain
‘unsolved’. The tool to deal with these kinds of bugs are unit tests and
>
> Sure, but saying "we'll never fix them all, so why even try?" is not a
> good argument. Saying that the solution is unit tests is true for every
> behaviour; moreover people who don't know this semantic wouldn't test for
> it.
>
>
>
I'm arguing that I feel this direction is not what I woul
Why shouldnt it start out as a library, then if it proves useful discuss
whether to include in elixir core?
My feeling is that this belongs outside a language, Erlang has too much stuff
included. This was probably the right call back when Erlang didnt have package
managers, but elixir has great
Three years later...
https://groups.google.com/forum/m/#!search/tallak$20unity/elixir-lang-core/Q2eO8dRqrmA
Happy about this too!
--
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 fro
You also have the pretty compact option:
’’’
map = (foo && Map.put(map, :foo, foo)) || map
’’’
You could make it pipeable by wrapping it in an anonymous function:
’’’
map
|> &((foo && Map.put(&1, :foo, foo)) || &1).()
’’’
--
You received this message because you are subscribed to the Google G
I think the proper name would be something like
```
transform_if(x, condition, fun)
```
--
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-core+uns
I would like to add a solution within the existing language:
```elixir
> list = [{:ok, 1}, {:ok, 2}, {:error, :fail}, {:ok, 4}]
> for el <- list, do: ({:ok, num} = el; num)
** (MatchError) no match of right hand side value: {:error, :fail}
```
I think this is reasonable.
Acctually the built in f
24 matches
Mail list logo
