Re: [elixir-core:10303] [Proposal] Strict matching comprehensions
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 filtering in `for` caught me off guard, I was
expecting for to fail unless all elements matched. So for me the better
solution would be to always make matching in `for` strict. But I guess this
is too late now for backwards compatibility. Another alternative to `for!`
would be:
```elixir
> list = [{:ok, 1}, {:ok, 2}, {:error, :fail}, {:ok, 4}]
> for {:ok, num} <- list, strict: true, do: num
** (MatchError) no match of right hand side value: {:error, :fail}
```
I don't like the use of the exclamation mark in `for!` because it has
little meaning relative to the existing use of the exclamation mark in
Elixir.
onsdag 9. juni 2021 kl. 13:17:04 UTC+2 skrev ad...@a-corp.co.uk:
> I also love the proposal.
>
> It's a shame we can't re-use the `with` semantics of `=` raising a match
> error in the for.
>
> My two cents is `for!` makes the most sense, and follows the conventions
> of other functions.
>
> Best
>
> Adam
>
> On 8 Jun 2021, at 18:18, Christopher Keele wrote:
>
> This feature would be very useful, I've experience this signature-change
> pain point before too (and kind of have been avoiding `for` ever since,
> TBH).
>
> I'm reluctant to increase the surface area of the language itself, what do
> you think about adding a `:strict` option to `for` instead of a new special
> form/kernel macro/operator?
>
> On Monday, June 7, 2021 at 9:50:45 AM UTC-7 eric.meado...@gmail.com wrote:
>
>> ## Background
>>
>> `for` comprehensions are one of the most powerful features in Elixir. It
>> supports both enumerable and bitstring generators, filters through boolean
>> expressions and pattern matching, collectibles with `:into` and folding
>> with `:reduce`.
>>
>> One of the features are automatic filtering by patterns in generators:
>>
>> ```elixir
>> list = [{:ok, 1}, {:ok, 2}, {:error, :fail}, {:ok, 4}]
>> for {:ok, num} <- list, do: num
>> #=> [1, 2, 4]
>> ```
>>
>> Generator filtering is very powerful because it allows you to succinctly
>> filter out data that is not relevant to the comprehension in the same
>> expression that you are generating elements out of your
>> enumerable/bitstrings. But the implicit filtering can be dangerous because
>> changes in the shape of the data will silently be removed which can cause
>> hard to catch bugs.
>>
>> The following example can show how this can be an issue when testing
>> `Posts.create/0`. If a change causes the function to start returning `{:ok,
>> %Post{}}` instead of the expected `%Post{}` the test will pass even though
>> we have a bug.
>>
>> ```elixir
>> test "create posts" do
>> posts = Posts.create()
>> for %Post{id: id} <- posts, do: assert is_integer(id)
>> end
>> ```
>>
>> The example uses a test to highlight the issue but it can just as well
>> happen in production code, specially when refactoring in other parts of the
>> code base than the comprehension.
>>
>> Elixir is a dynamically typed language but dynamic typing errors are less
>> of an issue compared to many other dynamic languages because we are usual
>> strict in the data we accept by using pattern matching and guard functions.
>> `for` is by design not strict on the shape of data it accepts and therefor
>> loses the nice property of early failure on incorrect data.
>>
>> ## Proposal
>>
>> I propose an alternative comprehension macro called `for!` that has the
>> same functionality as `for` but instead of filtering on patterns in
>> generators it will raise a `MatchError`.
>>
>> ```elixir
>> posts = [{:ok, %Post{}}]
>> for! %Post{id: id} <- posts, do: assert is_integer(id)
>> #=> ** (MatchError) no match of right hand side value: {:ok, %Post{}}
>> ```
>>
>> Pattern matching when not generating values with `=` remains unchanged.
>>
>> `for!` gives the developer an option to be strict on the data it accepts
>> instead of silently ignoring data that does not match.
>>
>> ## Other considerations
>>
>> You can get strict matching with `for` today by first assigning to a
>> variable. This way you can also mix filtering and strict matching patterns.
>>
>> ```elixir
>> posts = [{:ok, %Post{}}]
>> for post <- posts,
>> %Post{id: id} = post,
>> do: assert is_integer(id)
>> #=> ** (MatchError) no match of right hand side value: {:ok, %Post{}}
>> ```
>>
>> Another alternative is to introduce a new operator such as `<<-` (the
>> actual token can be anything, `<<-` is only used as an example) for raising
>> pattern matches instead of introducing a completely new macro.
>>
>> ```elixir
>> posts = [{:ok, %Post{}}]
>> for %Post{id: id} <<- posts, do: assert is_integer(id)
>> #=> ** (MatchError) no match of right hand side value: {:ok, %Post{}}
>> ```
>>
>> A downside of
Re: [elixir-core:9643] [Proposal] Add Map.put_if/4
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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/9334d4ba-d96c-466d-80e8-af0c20dc3f47o%40googlegroups.com.
[elixir-core:9642] [Proposal] Add Map.put_if/4
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 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 this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/884e3aea-0fd5-462f-ac71-d8e3695401eco%40googlegroups.com.
Re: [elixir-core:9297] [Proposal] identity function
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 from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/979f64d6-6626-4517-9702-716aa2af257e%40googlegroups.com.
[elixir-core:7997] [Proposal] Crypto module wrapper
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 package support... -- 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 this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/018f200b-6586-4c53-b3c9-2addc069a73b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [elixir-core:7603] Re: [Proposal] Introduce is_positive/1 and is_negative/1 macros
> > 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 would expect of Elixir, being a dynamically typed language. I would not trade "bloating the Kernel module" (sorry for not finding a nicer wording, I don't mean to be harsh) for this functionality. -- 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 this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/fec9809f-d415-4e12-a8ab-cc73f794847e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[elixir-core:7600] Re: [Proposal] Introduce is_positive/1 and is_negative/1 macros
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 dialyzer. -- 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 this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/e7227105-994d-4416-b829-17466b11da00%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[elixir-core:7597] [Proposal] Introduce is_positive/1 and is_negative/1 macros
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 group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/9a65bca0-411b-4e9f-9a50-e26ac19b29a0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[elixir-core:7499] Maybe Map.replace should lazily evaluate the new value, or introduce Map.replace_lazy?
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 optimized solution? 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...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/c356378b-2fa7-417e-8e20-406f5f7a86ed%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[elixir-core:7473] Maybe Map.replace should lazily evaluate the new value, or introduce Map.replace_lazy?
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 this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/0ef5d775-cbe6-4446-b986-e4fee7522013%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[elixir-core:7333] Re: [Proposal] Control block with annotations and no commas
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...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/513c8fc6-4060-4a28-a33b-630baa429cb2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[elixir-core:7151] Re: Proposal: pipe and assign syntax
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 "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 this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/d239d384-41aa-4bbc-96cd-e218fc0c8d43%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [elixir-core:6912] Any reason Enum.first and Enum.rest are not implemented?
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 iterated after) https://hex.pm/packages/stream_split For simple cases though it works well :) -- 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 this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/63b9a254-e3f6-41f3-8ba1-18de50d1ac86%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[elixir-core:6794] Pipeline-firendly variable assignment
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 (both interesting in isolation), we discover that actually 'less is more' For reference: https://gist.github.com/tallakt/a6701b1e5c2808c85104 See the test at the end for usage example -- 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 this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/8e5049f7-3941-43c3-a648-594419032e7a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[elixir-core:6597] Proposal: Enum.reject for Enum.compact
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 \\ fn x -> x end) ''' Actually I have also thought that a 'unity' or 'itself' function should be part of stdlib, to make this possible as: ''' list |> Enum.filter() ''' -- 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 this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/06bc7738-3ed9-4a21-9fce-b7eb3fecd600%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [elixir-core:6593] Flow.chunk ?
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 Flow.chunk would shuffle the order of the computation of each chunk, which would be an issue if order was important (as I assumed first time I read your post). So I must conclude perhaps that your code is working as designed? I won't comment on multiprocessing here. But as you are using `Flow` here, I would assume some kind of optimization is going on, and perhaps the initial sequence is quite long. I am thinking that the first `Enum.chunk(...)` might be very memory intensive, building lots and lots of lists, that must be copied as they are not the tail of the list. Perhaps using Stream.chunk would be a better choice here. There is also some kind of duplication going on with regard to "chunk B" as most of the chunks computed in the second iteration of "chunk A" would be exactly the same as those for the previous iteration. And they would all be reallocated. I guess some kind of dynamic programming (the algorithm) could be useful in this scenario. -- 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 this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/7da27c82-8078-4adf-b8ad-75373af08d6a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[elixir-core:6386] Re: Deprecate 'single quotes for char lists'
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-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 this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/892922fb-9790-4b4e-8b68-36d340ffc05c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [elixir-core:6089] Maybe Add A Warning For Including Commas In ~w List
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 receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/28e9e361-8b18-4c49-a79c-cbeb882742e2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[elixir-core:6001] Proposal: Rename lhs and rhs
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 word wrapping. -- 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 this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/2e7b57f4-0474-4dc5-be55-c088d7beebff%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
