> This is a separate convo but I don’t see value in adding a primary syntax for sets given we can’t really use it in pattern matching. A syntax for only adding and removing set elements is, IMO, not worth it.
I whole-heartedly agree. The indirection of our set implementation and lack of literals served us well during our transition off of HashSet <https://hexdocs.pm/elixir/HashSet.html>, towards MapSet <https://hexdocs.pm/elixir/MapSet.html>, and the motivating Collectable <https://hexdocs.pm/elixir/Collectable.html> protocol creation to support Enum.into/2 <https://hexdocs.pm/elixir/Enum.html#into/2> and enable for/1 :into macro support <https://hexdocs.pm/elixir/Kernel.SpecialForms.html#for/1-the-into-and-uniq-options>. Mind you, if erlang were to introduce a set literal at any point in the future, I would change my opinion here rapidly. On Thursday, June 29, 2023 at 4:04:16 AM UTC-5 José Valim wrote: > This is a separate convo but I don’t see value in adding a primary syntax > for sets given we can’t really use it in pattern matching. A syntax for > only adding and removing set elements is, IMO, not worth it. > > On Thu, Jun 29, 2023 at 11:21 Christopher Keele <christ...@gmail.com> > wrote: > >> > Just throwing it out there that this notation would make for a very >> nice MapSet literal. :) >> >> :D I am deeply convinced that this is why python, in its walrus operator >> attempt >> <https://docs.python.org/3/whatsnew/3.8.html#assignment-expressions> to >> keep up with Ruby features, has not offered a response to Ruby's Hash >> assignment destructuring of {foo:, bar:}: the {} literal syntax in >> python is already overloaded for both its native associative array literal >> construct (dicts) and set literal construct (sets), which share {} as >> delimiters and cause endless confusion already. >> >> On Thursday, June 29, 2023 at 3:14:51 AM UTC-5 woj...@wojtekmach.pl >> wrote: >> >>> > %{foo, bar} >>> >>> Just throwing it out there that this notation would make for a very nice >>> MapSet literal. :) >>> >>> On 29 Jun 2023, at 10:05, Christopher Keele <christ...@gmail.com> wrote: >>> >>> > There is another idea here, which is to fix this at the tooling level. >>> > >>> > For example, we could write %{foo, bar} and have the formatter >>> automatically expand it to: %{foo: foo, bar: bar}. >>> >>> I do like this notion, but am worried about fragmentation at the tooling >>> level. >>> >>> I see a syntax addition (even if an ephemeral operator, deprecated with >>> atom garbage collection) as an elegant way to traverse this. If we lean >>> into the syntax addition of this proposal, Paul does make a valid point: >>> >>> > Make the case why *extra* syntax is better than the more limited >>> barewords-only implementation, for example, by enabling support for string >>> keys, by offering a syntax construct that can be used in more places, etc. >>> >>> Hence the proposal. However, I think a constructive outcome of this >>> discussion could be proposing exactly that expansion to tooling >>> maintainers. :) >>> >>> On Thursday, June 29, 2023 at 2:59:39 AM UTC-5 Christopher Keele wrote: >>> >>>> > Another idea is to improve Elixir LS itself to suggest the variable >>>> name itself after ":". So if I type "%{foo:", it immediately suggests " >>>> foo". So, once again, easy to write, easy to read. >>>> >>>> I think this is part of the popularity of the opinion that some such >>>> syntax should only work for structs: with Elixir LS today, starting to >>>> type >>>> a `key:` in a struct/map literal does indeed suggest from the list of >>>> known >>>> struct keys. I don't see this being impossible in LS tooling today, but >>>> also don't know much about what is possible with the language server >>>> protocol today. :) >>>> On Thursday, June 29, 2023 at 2:54:28 AM UTC-5 José Valim wrote: >>>> >>>>> There is another idea here, which is to fix this at the tooling level. >>>>> >>>>> For example, we could write %{foo, bar} and have the formatter >>>>> automatically expand it to: %{foo: foo, bar: bar}. So you get the concise >>>>> syntax when writing, the clear syntax when reading. Since most editors >>>>> format on save nowadays, it can be beneficial. Executing code with the >>>>> shortcut syntax will print a warning saying you must format the source >>>>> file >>>>> before. >>>>> >>>>> Another idea is to improve Elixir LS itself to suggest the variable >>>>> name itself after ":". So if I type "%{foo:", it immediately suggests " >>>>> foo". So, once again, easy to write, easy to read. >>>>> >>>>> On Thu, Jun 29, 2023 at 9:49 AM Christopher Keele <christ...@gmail.com> >>>>> wrote: >>>>> >>>>>> > As a counter point: Ruby has added this feature as {foo:, bar:}, >>>>>> which would have a direct translation to Elixir. Source: >>>>>> https://bugs.ruby-lang.org/issues/14579 >>>>>> >>>>>> As a Rubyist who came to Elixir in the early days for personal >>>>>> projects before that Ruby syntax was implemented, and has only been >>>>>> professionally an engineering team manager of python, JS, and TS >>>>>> applications since: I like the explicitness of Ruby's notation here, but >>>>>> still really hate it how it reads and syntax highlights. :`) >>>>>> >>>>>> That is just a personal opinion though, out of context of the utility >>>>>> of this proposal. However, I believe that incarnation for Elixir has >>>>>> been >>>>>> proposed before, and I am just searching for alternatives that would >>>>>> still >>>>>> enable field punning sooner rather than later. >>>>>> >>>>>> > You are doing great. You defend your proposal and ideas. :) >>>>>> >>>>>> Thank you! It is not easy to defend a language syntax proposal I do >>>>>> not personally adore the syntax of; but I imagine that's what many >>>>>> people >>>>>> felt like for Ruby's equivalent, with {foo:, bar:} (as I did at the >>>>>> time). I earnestly believe that this idea could mitigate pain points >>>>>> with >>>>>> Elixir adoption while reasonably contending with ES6 barewords syntax we >>>>>> are not yet able to adopt. However, I would not be heartbroken if we >>>>>> agreed >>>>>> that waiting for Elixir 2.0 and/or atom garbage collection was the right >>>>>> play here. >>>>>> >>>>>> On Thursday, June 29, 2023 at 2:33:22 AM UTC-5 José Valim wrote: >>>>>> >>>>>>> > I would argue that if we want to support only atoms, but make it >>>>>>> clear that the syntax only applies to atoms, before an Elixir 2.0, we >>>>>>> must >>>>>>> leverage atom literals in the feature. The addition of a new operator >>>>>>> (or, >>>>>>> overloading of the capture operator in previous incarnations of this >>>>>>> proposal) is the only way to accomplish this today. >>>>>>> >>>>>>> As a counter point: Ruby has added this feature as {foo:, bar:}, >>>>>>> which would have a direct translation to Elixir. Source: >>>>>>> https://bugs.ruby-lang.org/issues/14579 >>>>>>> >>>>>>> > Apologies if it feels like I am trying to torpedo other solutions, >>>>>>> that is not my intent at all. >>>>>>> >>>>>>> You are doing great. You defend your proposal and ideas. :) >>>>>>> >>>>>>> On Thu, Jun 29, 2023 at 9:29 AM Christopher Keele < >>>>>>> christ...@gmail.com> wrote: >>>>>>> >>>>>>>> Honestly, I do not adore the syntax of the proposed solution, in >>>>>>>> either capture or $ operator incarnation. I would also prefer >>>>>>>> barewords. >>>>>>>> >>>>>>>> *Re: Paul's note:* >>>>>>>> >>>>>>>> > It is not at all clear to me why supporting string keys is >>>>>>>> critical to the feature >>>>>>>> >>>>>>>> 100%, Phoenix params parsing support. This is the major obvious >>>>>>>> use-case for full-stack devs today of this proposal. If garbage >>>>>>>> collection >>>>>>>> of atoms is implemented in erlang, we could deprecate the proposed >>>>>>>> syntax >>>>>>>> readily. >>>>>>>> >>>>>>>> Most of my personal Elixir development does not use Phoenix, so I >>>>>>>> do empathize with the sentiment and prefer atoms/barewords, but have >>>>>>>> tried >>>>>>>> to accommodate the outcry for this feature in this proposal, >>>>>>>> contending >>>>>>>> with popularity of JS's barewords implementation, concerning fullstack >>>>>>>> Phoenix development on >>>>>>>> >>>>>>>> > the Elixir forum (1 >>>>>>>> <https://elixirforum.com/t/proposal-add-field-puns-map-shorthand-to-elixir/15452> >>>>>>>> , 2 >>>>>>>> <https://elixirforum.com/t/shorthand-for-passing-variables-by-name/30583> >>>>>>>> , 3 >>>>>>>> <https://elixirforum.com/t/if-you-could-change-one-thing-in-elixir-language-what-you-would-change/19902/17> >>>>>>>> , 4 >>>>>>>> <https://elixirforum.com/t/has-map-shorthand-syntax-in-other-languages-caused-you-any-problems/15403> >>>>>>>> , 5 >>>>>>>> <https://elixirforum.com/t/es6-ish-property-value-shorthands-for-maps/1524> >>>>>>>> , 6 >>>>>>>> <https://elixirforum.com/t/struct-creation-pattern-matching-short-hand/7544> >>>>>>>> ) >>>>>>>> >>>>>>>> *Re: José's note:* >>>>>>>> >>>>>>>> > I agree with Paul that we don't need to support both strings and >>>>>>>> atoms, but it must be clear that it applies to either strings or atoms. >>>>>>>> >>>>>>>> I would also prefer only supporting atoms, or even as a compromise >>>>>>>> with string confusion, only structs. Previous proposals have flighted >>>>>>>> this >>>>>>>> before, and have not succeeded. >>>>>>>> >>>>>>>> I would argue that if we want to support only atoms, but make it >>>>>>>> clear that the syntax only applies to atoms, before an Elixir 2.0, we >>>>>>>> must >>>>>>>> leverage atom literals in the feature. The addition of a new operator >>>>>>>> (or, >>>>>>>> overloading of the capture operator in previous incarnations of this >>>>>>>> proposal) is the only way to accomplish this today. >>>>>>>> >>>>>>>> If we really wanted to drive this home, we could only support atom >>>>>>>> literals in the proposal, and drop the support for strings; however, I >>>>>>>> don't see a way to resolve this tension today without employing atom >>>>>>>> literals in the feature's syntax. >>>>>>>> >>>>>>>> *Re: Paul's note:* >>>>>>>> >>>>>>>> > I really don't want this thread to devolve into argument like >>>>>>>> many of the others on this topic, but making statements like "a >>>>>>>> barewords >>>>>>>> implementation is not viable in Elixir" is not doing any favors. It is >>>>>>>> factually untrue, and the premise of the statement is based entirely >>>>>>>> on an >>>>>>>> opinion. If this thread is going to have any hope of making progress, >>>>>>>> broad >>>>>>>> assertions of that nature better be backed up with a lot of objective >>>>>>>> data. >>>>>>>> >>>>>>>> I wish there were a data-driven way to approach language design. >>>>>>>> The only tool I know of is flighting proposals with working prototypes. >>>>>>>> >>>>>>>> > Make the case why *extra* syntax is better than the more limited >>>>>>>> barewords-only implementation, for example, by enabling support for >>>>>>>> string >>>>>>>> keys, by offering a syntax construct that can be used in more places, >>>>>>>> etc. >>>>>>>> It isn't necessary for your proposal to torpedo other solutions in >>>>>>>> order to >>>>>>>> succeed, and has a better chance of doing so if you don't. >>>>>>>> >>>>>>>> This proposal makes a case for this syntax being better than a more >>>>>>>> limited barewords-only implementation. Specifically, it enables >>>>>>>> support for >>>>>>>> string keys, and offers a syntax construct that can be used in more >>>>>>>> places >>>>>>>> (as a specific example, error = "rate limit exceeded"; $:error # >>>>>>>> return error tuple. Apologies if it feels like I am trying to >>>>>>>> torpedo other solutions, that is not my intent at all. >>>>>>>> On Thursday, June 29, 2023 at 2:02:04 AM UTC-5 José Valim wrote: >>>>>>>> >>>>>>>>> Hi Chris Keele, thank you for the excellent proposal. I just want >>>>>>>>> to add that I agree with Paul that we don't need to support both >>>>>>>>> strings >>>>>>>>> and atoms, but it must be clear that it applies to either strings or >>>>>>>>> atoms >>>>>>>>> (if it supports only one of them) and the reason for that is because >>>>>>>>> otherwise it will add to the string vs atom confusion that already >>>>>>>>> exists >>>>>>>>> in the language. Someone would easily write def show(conn, %{id}) and >>>>>>>>> be >>>>>>>>> surprised why it doesn't match. >>>>>>>>> >>>>>>>>> A couple additional thoughts to the thread: >>>>>>>>> >>>>>>>>> * : in JS and = in Haskell/OCaml are operators. : in Elixir is not >>>>>>>>> an operator >>>>>>>>> >>>>>>>>> * &:foo/$:foo as a shortcut for {:foo, foo} is interesting but >>>>>>>>> note that "foo: foo" already work as a shortcut in select places - so >>>>>>>>> we >>>>>>>>> would introduce more ways of doing something similar >>>>>>>>> >>>>>>>>> * Elixir and Ruby shares a lot syntax wise, it may be worth >>>>>>>>> revisiting what they do and which points arose in their >>>>>>>>> discussions/implementations >>>>>>>>> >>>>>>>>> On Thu, Jun 29, 2023 at 8:51 AM Paul Schoenfelder < >>>>>>>>> paulscho...@fastmail.com> wrote: >>>>>>>>> >>>>>>>>>> For reasons explained in Austin's reply >>>>>>>>>> <https://groups.google.com/g/elixir-lang-core/c/P6VprVlRd6k/m/ijxO7HdpAgAJ>, >>>>>>>>>> >>>>>>>>>> a "barewords" implementation is not viable in Elixir, because of the >>>>>>>>>> prevalence of both atom and string key types. >>>>>>>>>> >>>>>>>>>> IMO, discussing the nuance of if a barewords representation >>>>>>>>>> should prefer atoms or keys is what has been continually holding >>>>>>>>>> this >>>>>>>>>> feature up for a decade, and that's what this proposal tries to move >>>>>>>>>> past. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I don't agree that the rationale given by Austin is sufficient to >>>>>>>>>> reject a barewords-only implementation of field punning in Elixir. >>>>>>>>>> It is >>>>>>>>>> not at all clear to me why supporting string keys is critical to the >>>>>>>>>> feature, and I especially don't find the argument that people will >>>>>>>>>> ignore >>>>>>>>>> all of the plentiful advice about avoiding atom table exhaustion >>>>>>>>>> just so >>>>>>>>>> they can use field punning (e.g. switching to `Jason.parse(.., keys: >>>>>>>>>> atoms)`) compelling, at all. There will always be people who find a >>>>>>>>>> way to >>>>>>>>>> do dumb things in their code, but languages (thankfully) don't base >>>>>>>>>> their >>>>>>>>>> designs on the premise that most of their users are idiots, and I >>>>>>>>>> don't see >>>>>>>>>> why it would be any different here. >>>>>>>>>> >>>>>>>>>> I've seen this debate come up over and over since the very first >>>>>>>>>> time it was brought up on this list, and there is a good reason why >>>>>>>>>> it >>>>>>>>>> keeps dying on the vine. The justification for field punning is weak >>>>>>>>>> to >>>>>>>>>> begin with, largely sugar that benefits the code author rather than >>>>>>>>>> the >>>>>>>>>> reader, and syntax sugar must carry its own weight in the language, >>>>>>>>>> and the >>>>>>>>>> only chance of that here is by building on the foundations laid by >>>>>>>>>> other >>>>>>>>>> languages which have it. Doing so means readers are much more likely >>>>>>>>>> to >>>>>>>>>> recognize the syntax for what it is, it adds no new >>>>>>>>>> sigils/operators, and >>>>>>>>>> it is narrowly scoped yet still convenient in many common scenarios. >>>>>>>>>> If >>>>>>>>>> anything, the desire to make this work for string keys is what keeps >>>>>>>>>> killing this feature, not the other way around. >>>>>>>>>> >>>>>>>>>> I really don't want this thread to devolve into argument like >>>>>>>>>> many of the others on this topic, but making statements like "a >>>>>>>>>> barewords >>>>>>>>>> implementation is not viable in Elixir" is not doing any favors. It >>>>>>>>>> is >>>>>>>>>> factually untrue, and the premise of the statement is based entirely >>>>>>>>>> on an >>>>>>>>>> opinion. If this thread is going to have any hope of making >>>>>>>>>> progress, broad >>>>>>>>>> assertions of that nature better be backed up with a lot of >>>>>>>>>> objective data. >>>>>>>>>> Make the case why *extra* syntax is better than the more limited >>>>>>>>>> barewords-only implementation, for example, by enabling support for >>>>>>>>>> string >>>>>>>>>> keys, by offering a syntax construct that can be used in more >>>>>>>>>> places, etc. >>>>>>>>>> It isn't necessary for your proposal to torpedo other solutions in >>>>>>>>>> order to >>>>>>>>>> succeed, and has a better chance of doing so if you don't. >>>>>>>>>> >>>>>>>>>> Paul >>>>>>>>>> >>>>>>>>>> On Thu, Jun 29, 2023, at 12:40 AM, Christopher Keele wrote: >>>>>>>>>> >>>>>>>>>> > This proposal mentions OCaml, Haskell and JS as prior works of >>>>>>>>>> art for >>>>>>>>>> > this type of feature. I think a key thing to point out is that >>>>>>>>>> in those >>>>>>>>>> > languages, they did not need to add additional syntax in order >>>>>>>>>> to >>>>>>>>>> > support this. >>>>>>>>>> >>>>>>>>>> This is true, and the discomfort extends to Ruby as well. >>>>>>>>>> >>>>>>>>>> For reasons explained in Austin's reply >>>>>>>>>> <https://groups.google.com/g/elixir-lang-core/c/P6VprVlRd6k/m/ijxO7HdpAgAJ>, >>>>>>>>>> >>>>>>>>>> a "barewords" implementation is not viable in Elixir, because of the >>>>>>>>>> prevalence of both atom and string key types. >>>>>>>>>> >>>>>>>>>> IMO, discussing the nuance of if a barewords representation >>>>>>>>>> should prefer atoms or keys is what has been continually holding >>>>>>>>>> this >>>>>>>>>> feature up for a decade, and that's what this proposal tries to move >>>>>>>>>> past. >>>>>>>>>> >>>>>>>>>> Perhaps in an ideal Elixir 2.0 future if we get garbage >>>>>>>>>> collection of atoms like Ruby, Phoenix can move over to parsing >>>>>>>>>> params with >>>>>>>>>> atom-based key pairs, we can drop the operator and atom/string >>>>>>>>>> differentiation, and move the entire syntax over to barewords. Worth >>>>>>>>>> calling out that this proposal (with a new operator, not the capture >>>>>>>>>> operator) could remain backwards-compatible with the proposed syntax >>>>>>>>>> if we >>>>>>>>>> moved into an atom-oriented Phoenix params parsing Elixir 2.0 future. >>>>>>>>>> >>>>>>>>>> As Elixir 2.0 may never get released, famously, this is the only >>>>>>>>>> clear path I see forward for our production applications today to >>>>>>>>>> get field >>>>>>>>>> punning, that skirts issues with prior art. >>>>>>>>>> On Wednesday, June 28, 2023 at 11:27:48 PM UTC-5 me wrote: >>>>>>>>>> >>>>>>>>>> This proposal mentions OCaml, Haskell and JS as prior works of >>>>>>>>>> art for >>>>>>>>>> this type of feature. I think a key thing to point out is that in >>>>>>>>>> those >>>>>>>>>> languages, they did not need to add additional syntax in order to >>>>>>>>>> support this. >>>>>>>>>> >>>>>>>>>> In OCaml, the syntax goes from >>>>>>>>>> >>>>>>>>>> { foo = foo; bar = bar } >>>>>>>>>> >>>>>>>>>> to >>>>>>>>>> >>>>>>>>>> { foo; bar } >>>>>>>>>> >>>>>>>>>> Haskell starts with >>>>>>>>>> >>>>>>>>>> C { foo = foo, bar = bar } >>>>>>>>>> >>>>>>>>>> and turns into >>>>>>>>>> >>>>>>>>>> C { foo, bar } >>>>>>>>>> >>>>>>>>>> And lastly, Javascript uses >>>>>>>>>> >>>>>>>>>> { foo: foo, bar: bar } >>>>>>>>>> >>>>>>>>>> which can be used as >>>>>>>>>> >>>>>>>>>> { foo, bar } >>>>>>>>>> >>>>>>>>>> Note the lack of additional syntax surrounding these features. >>>>>>>>>> >>>>>>>>>> > {foo, bar, baz} = {1, 2, 3} >>>>>>>>>> > >>>>>>>>>> > %{$:foo, "fizz" => "buzz", $"bar", fizz: :buzz} >>>>>>>>>> > # => %{:fizz => :buzz, :foo => 1, "bar" => 2, "fizz" => "buzz"} >>>>>>>>>> >>>>>>>>>> If I were coming from one of the above languages (or any other >>>>>>>>>> language >>>>>>>>>> that supports this feature), I would not look at this syntax and >>>>>>>>>> say >>>>>>>>>> "This is field punning". I would have no intuition what is going >>>>>>>>>> on. >>>>>>>>>> >>>>>>>>>> Speaking as someone that has a decent amount of Elixir experience, >>>>>>>>>> $"bar" looks like it should be closer in functionality to :"bar" >>>>>>>>>> than >>>>>>>>>> field punning. Or maybe even similar to using ? to find the >>>>>>>>>> codepoint of >>>>>>>>>> a single character. Something to keep in mind, Erlang actually >>>>>>>>>> uses $ >>>>>>>>>> for the same purpose that Elixir uses ?. I'm not saying Elixir >>>>>>>>>> couldn't >>>>>>>>>> use the same token/operator for a different purpose, I just think >>>>>>>>>> it is >>>>>>>>>> something that should be considered. >>>>>>>>>> >>>>>>>>>> Justin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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-co...@googlegroups.com. >>>>>>>>>> To view this discussion on the web visit >>>>>>>>>> https://groups.google.com/d/msgid/elixir-lang-core/aee0f98a-9b9b-4ff0-9a48-08d4e31df8c5n%40googlegroups.com >>>>>>>>>> >>>>>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/aee0f98a-9b9b-4ff0-9a48-08d4e31df8c5n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>>> . >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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-co...@googlegroups.com. >>>>>>>>>> >>>>>>>>> To view this discussion on the web visit >>>>>>>>>> https://groups.google.com/d/msgid/elixir-lang-core/72586965-c3ee-42c0-b7d3-7e863ace2706%40app.fastmail.com >>>>>>>>>> >>>>>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/72586965-c3ee-42c0-b7d3-7e863ace2706%40app.fastmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>> . >>>>>>>>>> >>>>>>>>> >>>>>>>> -- >>>>>>>> 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-co...@googlegroups.com. >>>>>>>> >>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/d/msgid/elixir-lang-core/7134e702-f9b2-44ad-bf33-3b8a633862d7n%40googlegroups.com >>>>>>>> >>>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/7134e702-f9b2-44ad-bf33-3b8a633862d7n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>> >>>>>> -- >>>>>> 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-co...@googlegroups.com. >>>>>> >>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/elixir-lang-core/d265a338-e815-4e6b-a541-e61e2ec89611n%40googlegroups.com >>>>>> >>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/d265a338-e815-4e6b-a541-e61e2ec89611n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> >>> -- >>> 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-co...@googlegroups.com. >>> >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/elixir-lang-core/d0d6b9a6-b2d0-4a83-8cc0-f8580e151404n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/elixir-lang-core/d0d6b9a6-b2d0-4a83-8cc0-f8580e151404n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> >>> -- >> 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-co...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/4b0b7343-2d02-4424-9341-8d33c45be40fn%40googlegroups.com >> >> <https://groups.google.com/d/msgid/elixir-lang-core/4b0b7343-2d02-4424-9341-8d33c45be40fn%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/cdadb6a0-9bee-434c-8243-928ec9f872e5n%40googlegroups.com.
