[elixir-core:8482] [Proposal] Support function captures without the need for any argument

Hello, Elixir could support function captures without the need for any argument, so that of instead of writing fn () -> M.fun("value") end one could write &M.fun("value") Today the later returns an error like ** (CompileError) iex:28: invalid args for &, expected an expression in the

[elixir-core:8483] Re: [Proposal] Support function captures without the need for any argument

Where is fn () -> M.fun("value") it should be fn () -> M.fun("value") end or fn -> M.fun("value") end quinta-feira, 14 de Fevereiro de 2019 às 16:46:18 UTC, Mário Guimarães escreveu: > > Hello, > > Elixir could support function captur

Re: [elixir-core:8486] Re: [Proposal] Support function captures without the need for any argument

pardi > wrote: > >> Hey Mario, >> >> The capture operator today already has a few forms (arity or arguments) >> and I think it would be better to keep it simple and not add more specific >> behaviors, especially considering this would be done to save ju

[elixir-core:8489] What does %Mod{} really do?

Hello, given the files `xx.ex` and `yy.ex` defined as defmodule XX do defstruct [:field] end defmodule YY do defdelegate __struct__, to: XX defdelegate __struct__(x), to: XX end why does iex(1)> %XX{} == XX.__struct__() true and iex(2)> %YY{} == YY.__struct__() false ? It seems tha

Re: [elixir-core:8490] What does %Mod{} really do?

; www.plataformatec.com.br > Skype: jv.ptec > Founder and Director of R&D > > > On Fri, Feb 15, 2019 at 2:47 PM Mário Guimarães > wrote: > >> Hello, >> >> given the files `xx.ex` and `yy.ex` defined as >> >> defmodule XX do >> defstruct [:f

Re: [elixir-core:8491] What does %Mod{} really do?

Reported on https://github.com/elixir-lang/elixir/issues/8800 sexta-feira, 15 de Fevereiro de 2019 às 16:33:18 UTC, Mário Guimarães escreveu: > > Ok, I will write a report > > sexta-feira, 15 de Fevereiro de 2019 às 15:48:31 UTC, José Valim escreveu: >> >> Please do

[elixir-core:8509] Making "@fallback_to_any true" more flexible

Hello, I was trying to make a default implementation of a protocol via defprotocol TheProtocol do def fun1(...) def fun2(...) end defimpl TheProtocol, for: Any do def fun1(...) do end def fun2(...) do end end where "TheProtocol" defines several functions. Then I was trying

Re: [elixir-core:8511] Making "@fallback_to_any true" more flexible

. Anyway, thanks for your response. Mário Guimarães quarta-feira, 27 de Fevereiro de 2019 às 17:44:40 UTC, José Valim escreveu: > > Protocols do not provide default implementations for functions on purpose, > as that would make it easier for developers to write large protocols, while >

[elixir-core:8548] [Proposal] defnotoverridable

e` indicates a possibility, whereas `defnotoverridable` indicates an impossibility) 2) a `defnotoverridable [foo: 1]` requires function `foo/1` to have been defined before I hope you find this addition useful. Thanks, Mário Guimarães -- You received this message because you are subscribed to the Google

[elixir-core:8554] Re: [Proposal] defnotoverridable

rning for task/1. I don't know the internals to understand if this is something hard or even feasible to do, but at least, both the problem and a potential solution have been documented. Thanks Mário Guimarães quinta-feira, 21 de Março de 2019 às 17:31:36 UTC, Chris Russo escreveu: > >

[elixir-core:8602] More convenient defdelegate

Hello a suggestion: it would be convenient to write defdelegate foo/4, ... instead of having to write defdelegate foo(a, b, c, d), ... What do you think? Thanks Mário -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from

[elixir-core:8603] Re: More convenient defdelegate

It should be possible though to support both idioms, that is, the more succint `foo/n` and those supported today. quinta-feira, 4 de Abril de 2019 às 17:02:02 UTC+1, Mário Guimarães escreveu: > > Hello > > a suggestion: > > it would be convenient to write >

Re: [elixir-core:8605] More convenient defdelegate

It will not reduce the amount of information, which can be found on the target module. But I understand your point, and that's why I propose the more succinct idiom has an addition to the current idioms. quinta-feira, 4 de Abril de 2019 às 17:26:44 UTC+1, Rich Morin escreveu: > > Although you

Re: [elixir-core:8607] More convenient defdelegate

; lexical information, as mentioned by Rich, it doesn't justify adding > another API to defdelegate. The current API was made explicit on purpose. > > > *José Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Director of R&D > > > On Thu, Apr 4, 2019

[elixir-core:8609] Missing tuple access idioms

Hello, any reason why there are no easy readable idioms like first, snd, third, ..., tenth (I guess is enough) to access tuples? Thanks -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving ema

Re: [elixir-core:8613] Missing tuple access idioms

Hi José there are occasions like when doing ... |> Enum.map(&first) |> ... where pattern matching does not apply, and .. |> Enum.map(&elem(&1,0)) |> ... is much less readable. It was regarding these cases that I thought about tuple accessors. Mário Guimarães sexta-f

Re: [elixir-core:8615] Missing tuple access idioms

e one you mentioned, I > would go with |> Enum.map(fn {x, _, _} -> x end). > > On Fri, 5 Apr 2019 at 14:46, Mário Guimarães > wrote: > >> Hi José >> >> there are occasions like when doing ... |> Enum.map(&first) |> ... where >> pattern matching do

[elixir-core:8616] Give warning on unused require

Hi, I suggest for Elixir to warn on unused requires, like it does for unused aliases. Thanks -- 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-

Re: [elixir-core:8620] Re: Give warning on unused require

er here but it seems like > it is always possible as all information is available at compile time. > > Cheers, > Louis > > On Mon, 8 Apr 2019, 09:19 Łukasz Niemier, > > wrote: > >> Not possible as `require`s are *always* used - by the compiler, as this >&

Re: [elixir-core:8622] Re: Give warning on unused require

guaranteed by Elixir compiler) to work properly. So as you can > see the compiler has no knowledge whether it can alter compilation order > restricted by user. > > Of course this is highly unlike scenario for `require`, but is perfectly > valid code right now, with very well de

Re: [elixir-core:8626] Re: Give warning on unused require

Łukasz Niemier, > > wrote: >> >>> Not possible as `require`s are *always* used - by the compiler, as this >>> marks that required module need to be compiled before compilation of module >>> with require. >>> >>> W dniu piątek, 5 kwietnia

[elixir-core:8635] Provide better warning of unmatchable clauses in the presence of default arguments

(3)> X.foo(:a, :z, :c) {:a, :z, :c} {:a, :z, :c} It would be more clear if Elixir could report the actual clauses that cannot be called. Thanks Mário Guimarães -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe

[elixir-core:8636] Re: Provide better warning of unmatchable clauses in the presence of default arguments

-feira, 12 de Abril de 2019 às 14:49:59 UTC+1, Mário Guimarães escreveu: > > Hello > > given the following module > > defmodule X do > def foo(a, c), do: foo(a, :b, c) > def foo(a, b \\ "2", c \\ "3"), do: IO.inspect {a, b, c} > end > > E

Re: [elixir-core:8681] Error handling in Elixir [FORKED FROM Proposal Tuple.ok/1 and Tuple.error]

Hi, Can you provide us with a real code example that illustrates well your pain? Thanks Mário A qua, 17/04/2019, 06:08, Anil Kulkarni escreveu: > Hi all, > > Hopefully this isn't too large a tangent: > > One thing that I have consistently found in my projects is that error > handling is very t

[elixir-core:8735] [Proposal] Add a default value to Module.get_attribute

Hello, I suggest for Module.get_attribute(module, key) to receive a default value in case the attribute does not exist. The default value if not passed would be nil. The result would be Module.get_attribute(module, key, default \\ nil) This is a convenience that exists in many other function

Re: [elixir-core:8741] [Proposal] Add a default value to Module.get_attribute

R&D > > > On Fri, May 10, 2019 at 11:16 AM Mário Guimarães > wrote: > >> Hello, >> >> I suggest for >> >> Module.get_attribute(module, key) >> >> to receive a default value in case the attribute does not exist. The >> default value if n

[elixir-core:8780] Proposal: new syntax for pattern matching of maps

Hi, what if Elixir supported this new syntax for pattern matching of maps, in which for example, %{key1, key2} would be the same as %{key1: key1, key2: key2} Also, the following %{key1, ^key2} would be the same as %{key1: key1, key2: ^key2} What do you think? I find myself repeating this

Re: [elixir-core:8782] Proposal: new syntax for pattern matching of maps

Hi José, sorry for duplicating this again. I have just read your opinion here and it makes sense. Thanks Mário terça-feira, 21 de Maio de 2019 às 01:10:37 UTC+1, José Valim escreveu: > > Hi Mario, > > This has been pr

[elixir-core:8839] Provide DateTime.from_iso8601!/2

Hello, all "from_x" functions in DateTime support their throw exception version, but the function "from_iso8601/2" which returns an error tuple. Doesn't it make sense, because of convenience and completeness, to provide a bang version of this function? See https://hexdocs.pm/elixir/DateTime.ht

[elixir-core:8840] Re: Provide DateTime.from_iso8601!/2

tError, "cannot convert #{string} to datetime, reason: #{inspect(reason)}" end end segunda-feira, 17 de Junho de 2019 às 15:18:29 UTC+1, Mário Guimarães escreveu: > > Hello, > > all "from_x" functions in DateTime support their throw exception version, > but th

[elixir-core:8929] Proposal: allow to omit actual arguments to functions when they have default values

Hi, when a function is defined like def fun(a, b \\ 1, c \\ 2) there is no way to call it by omitting the second argument, that is, one must call fun(a, 1, c) The idea of this proposal is to support the calling idiom `fun(a, _, c)` as the equivalent of calling fun(a, 1, c) That is, in a f

Re: [elixir-core:8931] Proposal: allow to omit actual arguments to functions when they have default values

Founder and Director of R&D > > > On Tue, Jul 9, 2019 at 9:30 PM Mário Guimarães > wrote: > >> Hi, >> >> when a function is defined like >> >> def fun(a, b \\ 1, c \\ 2) >> >> there is no way to call it by omitting the second argume

[elixir-core:8948] [Proposal] Document the Big-O complexity (time and space) of every collection and their functions

Hi, I find this can be useful in selecting the collections and their manipulating functions to be used in our code. The case is that in an immutable language it may not be evident what is the O(...) of the insert, read, update, delete and sort, in our collections. For example, what is the comp

[elixir-core:8954] Re: [Proposal] Document the Big-O complexity (time and space) of every collection and their functions

I would suggest then to have @doc time: "O(n)" and @doc space: "O(n^2)" to clearly refer to time and space complexity of the function. Mário quinta-feira, 18 de Julho de 2019 às 17:36:04 UTC+1, Mário Guimarães escreveu: > > Hi, > > I find this can be use

Re: [elixir-core:8959] Re: [Proposal] Document the Big-O complexity (time and space) of every collection and their functions

matic in the future. > > Michał. > On 19 Jul 2019, 00:01 +0200, José Valim >, wrote: > > I like that. Maybe time_complexity / space_complexity for clarity. > > > *José Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Director of R&D > > > On

[elixir-core:8963] Re: [Proposal] Document the Big-O complexity (time and space) of every collection and their functions

or common operations on commonly-used >> datastructures would be the way to go. These unstructured documentation >> snippets might be accompanied by their formal complexity notations, but >> should not only consist of these. >> >> ~Qqwy/Marten >> >> On Thurs

Re: [elixir-core:8966] Re: [Proposal] Document the Big-O complexity (time and space) of every collection and their functions

nt data structures and algorithms. I don't think this proposal is > needed to solve that problem and it creates more complexities than benefits. > > On Fri, Jul 19, 2019 at 7:26 AM Mário Guimarães > wrote: > >> >> The idea of this proposal is to document time and space

Re: [elixir-core:8968] Re: [Proposal] Document the Big-O complexity (time and space) of every collection and their functions

mentation > why not put everything there? I'm not saying that we shouldn't communicate > this information when its useful. But it hasn't been proven to me that we > need an addition to the language to accomplish that goal. > > On Fri, Jul 19, 2019 at 11:00 AM Mário Guim

Re: [elixir-core:8970] Re: [Proposal] Document the Big-O complexity (time and space) of every collection and their functions

and more clarity using all of our existing tools. > > > Oh, that was already explained: > > I understand what you're proposing. But showing a table isn't a *problem*. > It's one solution to a problem. I'm not convinced this proposal adequately > sol

[elixir-core:8985] [Proposal] Map.put_new!

Hello, presently there is no function that throws an error in case we want to put a really new key in a map. The function Map.put_new only does nothing if the key is already there. The idea for Map.put_new! is to throw an error if the key is there. The use case is the developer who wants to be

[elixir-core:8986] Re: [Proposal] Map.put_new!

many of us found very infrequent or no use so far ¯\_(ツ)_/¯ My opinion is that it can be useful to make the code more bulletproof, much like Map.replace!/update! do. Mário quarta-feira, 24 de Julho de 2019 às 17:47:34 UTC+1, Mário Guimarães escreveu: > > Hello, > > presently the

Re: [elixir-core:9008] Re: [Proposal] Map.put_new!

I have implemented like this defmodule KeyFoundError do defexception [:key, :term] def message(%__MODULE__{key: key, term: term}) do "key #{inspect(key)} found in: #{inspect(term)}" end end defmodule MyMap do def put_new!(map, key, value) do if Map.has_key?(map, key) do rai

[elixir-core:9232] Re: Automatically time long-running iex commands.

+1 on this nice proposal. terça-feira, 6 de Agosto de 2019 às 23:51:17 UTC+1, Exempll escreveu: > > > This would be a neat detail. It is easy to forget to time a long-running > function, and sometimes, when you are surprised by the running time, you > want to know how long it ran for in retros

Re: [elixir-core:9237] Re: Add Enum.reverse_sort/1 and Enum.reverse_sort_by/2

Hello for me, the current sort function seems very clear: in the resulting enumeration, the predicate will be true for any two adjacent elements. iex(14)> 1..10 |> Enum.to_list [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] iex(15)> Enum.sort(1..10, &>=/2) [10, 9, 8, 7, 6, 5, 4, 3, 2, 1] iex(16)> 10..1 |> Enu

[elixir-core:9238] Re: Add Enum.reverse_sort/1 and Enum.reverse_sort_by/2

Hello for me, the current sort function seems very clear: in the resulting enumeration, the predicate will be true for any two adjacent elements. iex(14)> 1..10 |> Enum.to_list [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] iex(15)> Enum.sort(1..10, &>=/2) [10, 9, 8, 7, 6, 5, 4, 3, 2, 1] iex(16)> 10..1 |> En

[elixir-core:9446] Make IEx start even when some modules do not compile

sion. Do you think this would be useful ? Thanks Mário Guimarães -- 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...@goog

Re: [elixir-core:9448] Make IEx start even when some modules do not compile

: > > "iex -S mix" also starts your application and it is very likely we won't > be able to start your application, or it would behave poorly, if not all > code has been compiled. > > On Tue, Mar 31, 2020 at 1:50 PM Mário Guimarães > wrote: > >> He

Re: [elixir-core:9450] Make IEx start even when some modules do not compile

That will work, I believe, though it is not so much convenient in comparison to a way to compile everything that changed in the project and load only what did compile successfully. But thanks for reminding me about the `c/2` function. terça-feira, 31 de Março de 2020 às 15:03:21 UTC+1, J.H. Alm

[elixir-core:9473] Support module attributes inside << ... >>

lixir_bitstring.expand/4 (stdlib) lists.erl:1354: :lists.mapfoldl/3 (stdlib) lists.erl:1355: :lists.mapfoldl/3 (elixir) expanding macro: Kernel.@/1 Thanks Mário Guimarães -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.

[elixir-core:9474] Re: Support module attributes inside << ... >>

I discovered that it is possible to achieve the same effect this way defmodule MyModule do @param 8 param = @param @bin << 0 :: size(param) >> end so perhaps this is enough. Thanks terça-feira, 21 de Abril de 2020 às 11:28:59 UTC+1, Mário Guimarães escreveu: > > Hell

[elixir-core:9586] Shouldn't empty if .. do ..else blocks give a compilation error instead ?

Hello, I just observed the following cases iex(3)> if true do ...(3)> else ...(3)> :ok ...(3)> end nil iex(4)> if false do ...(4)> :ok ...(4)> else ...(4)> end nil iex(5)> if :anything do ...(5)> else ...(5)> end nil iex(6)> Should't they give a compilation error instead due to the empty blocks?

Re: [elixir-core:9592] Shouldn't empty if .. do ..else blocks give a compilation error instead ?

x27;m not against a compilation warning here, but there's > a chance we decided to not emit that for a reason that I can't recall right > now 😅 > > Andrea > > On Wed, 24 Jun 2020 at 13:19, Mário Guimarães > wrote: > >> Hello, >> >> I jus

Re: [elixir-core:10006] Add Enum.every?

I totally agree with Xavier. A qui, 21/01/2021, 13:33, Xavier Noria escreveu: > To me, this is like adding an option to any? Let's imagine: any?(enum, > on_empty: true). > > You'd say, man, how can you special-case the enum like that, the predicate > is about finding some element! If there is no