is 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/
ent behavior for nil while Atom.to_string keeps a literal
> conversion.
>
> On Wednesday, June 1, 2016, eksperimental
> <eksperimen...@autistici.org> wrote:
>
> > I came across when writing a macro that created functions after
> > atoms. I had the idead
to be converted to a list to later pick one element.
It optimized Enum.at/2 when dealing with ranges.
Thank you.
On Sat, 4 Jun 2016 08:37:19 +0700
eksperimental <eksperimen...@autistici.org> wrote:
> I forgot to mention that Range.at/3 has been implemented.
>
> ***
> ### Range.
Jose could you please give me an answer on this,
as I would like to to finally make it into the Elixir.
Thank you
On Thu, 5 May 2016 11:56:47 +0700
eksperimental <eksperimen...@autistici.org> wrote:
> Jose,
> It was earlier suggested that we should have a function like this.
> C
ular, if we implement Enum.random fast enough for ranges, it
> would be enough to replace many of the other functions listed, like
> Integer.random and Range.random. :)
>
>
>
> *José Valim*
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Director of R
>
gt;
>
> *José Valim*
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Director of R
>
> On Mon, May 9, 2016 at 4:43 AM, eksperimental
> <eksperimen...@autistici.org> wrote:
>
> > I'm trying to fix this bug.
> > https://github.com/elixir-lang/el
gt; move the cursor when reading bytes. We would actually need to load
> >> the file into Elixir. It would probably be more interesting to add
> >> a File.position instead of hiding the underlying behaviour.
> >>
> >>
> >> *José Valim*
> >> www.plata
cribe 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/20160512192534.35e62698.eksperimental%40autistici.org.
For more options, visit https://groups.google.com/d/optout.
wrote:
> Thank you Eksperimental for a great and detailed proposal with working
> implementation.
>
> My biggest concern is that the "kinds" are not extensible. We are
> replacing something that is extensible (defining functions) with an
> atom-tuple based lookup that i
sit
https://groups.google.com/d/msgid/elixir-lang-core/20160718222830.4f1c21d4.eksperimental%40autistici.org.
For more options, visit https://groups.google.com/d/optout.
atible change if no APIs change. It also depends on if the
> > type is used as arguments to functions or as return values.
> > Accepting more values in arguments is backwards compatible, but
> > returning more types of values is not.
> >
> > The solution might
-lang-core/20160704233754.6acc2ca5.eksperimental%40autistici.org.
For more options, visit https://groups.google.com/d/optout.
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/20160808212901.1360e245.eksperimental%40autistici.org.
For more options, visit https://groups.google.com/d/optout.
he finds some time. :)
>
>
>
> *José Valim*
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Director of R
>
> On Tue, Feb 21, 2017 at 3:46 PM, eksperimental <eksperimen...@autistici.org>
> wrote:
>
> > I would like to read at the documentation, and be a
m.br
> Skype: jv.ptec
> Founder and Director of R
>
> On Tue, Feb 21, 2017 at 3:38 PM, eksperimental <eksperimen...@autistici.org>
> wrote:
>
> > Hi, List.starts_with?/2 have recently been introduced
> > https://github.com/elixir-lang/elixir/pull/5789
> >
e+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/20170222090523.767b36c1.eksperimental%40autistici.org.
For more options, visit https://groups.google.com/d/optout.
.br
> Skype: jv.ptec
> Founder and Director of R
>
> On Tue, Feb 21, 2017 at 7:03 PM, eksperimental <eksperimen...@autistici.org>
> wrote:
>
> > Sorry José, I was wrong when i wrote
> > > If we support improper lists, prefix could be any term, not just a list.
> >
gt; > Thoughts?
> >
> > *José Valim*
> > www.plataformatec.com.br
> > Skype: jv.ptec
> > Founder and Director of R
> >
>
--
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/20160923210603.67c79cf8.eksperimental%40autistici.org.
For more options, visit https://groups.google.com/d/optout.
ar Elixir macro and not a typespec construct.
>
>
>
> *José Valim*
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Director of R
>
> On Wed, Oct 12, 2016 at 7:46 PM, eksperimental <eksperimen...@autistici.org>
> wrote:
>
> > Hi,
> > I'm
isit
> > https://groups.google.com/d/msgid/elixir-lang-core/6bf79af0-6f26-42f7-83e6-35c7f0b7c37f%40googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
--
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/20161212040836.157f25b6.eksperimental%40autistici.org.
For more options, visit https://groups.google.com/d/optout.
t; www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Director of R
>
> On Thu, Apr 13, 2017 at 4:55 PM, eksperimental <eksperimen...@autistici.org>
> wrote:
>
> > I'm working on improving the Makefile of Elixir, and I'm going through
> > what's being ignored
cause 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
I will submit a PR then
On Mon, 29 May 2017 06:34:20 +
José Valim <jose.va...@plataformatec.com.br> wrote:
> Yes, I would say that it is incomplete.
>
> On Mon, May 29, 2017 at 02:55 eksperimental <eksperimen...@autistici.org>
> wrote:
>
> > Working in the
Working in the latests addition to doctests let me found this bug,
This is an actual test,
defmodule ExUnit.DocTestTest.Incomplete do
@doc ~S'''
iex> 1 + 2
'''
def test_fun, do: :ok
end
it fails because there is nothing to evaluate against at the end of the doctest,
But I see that
omments (#=>, #>>) cannot be treated as regular comments,
because doctests will
always validate with them. And yes, they are not evaluated (that's the whole
point of having them),
otherwise we would just use regular code.
Please have a look at the final implementation.
https://gi
ote do: ...
but without putting the logic inside a quote (which will be invalid in a guard),
and unquoting kind to get the value from its calling environment.
thank you.
On Sat, 13 Aug 2016 02:22:09 +0700
eksperimental <eksperimen...@autistici.org> wrote:
> the Comparison group of kin
0170508221600.66851fc4.eksperimental%40autistici.org.
For more options, visit https://groups.google.com/d/optout.
wd and ls are not going to be effective in doctests as the results will be
> highly dependent of the user directory and what is on their machine.
>
>
>
> *José Valim*
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Director of R
>
> On Mon, May 8, 201
API to do exactly that. Such as File.ls! and
> File.cwd!.
>
>
>
> *José Valim*
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Director of R
>
> On Mon, May 8, 2017 at 6:26 PM, eksperimental <eksperimen...@autistici.org>
> wrote:
>
>
; Founder and Director of R
>
> On Mon, May 8, 2017 at 4:59 PM, eksperimental <eksperimen...@autistici.org>
> wrote:
>
> > I have been working on a few improvements for doctests.
> > Everything that I'm proposing here has already been implemented.
> > The propos
rt, {self(), :close}
#=> {#PID<0.80.0>, :close}
iex> flush()
#>> {#Port<0.1444>, :closed}
:ok
The implemented and tested code can be found here:
https://github.com/eksperimental/elixir/tree/doctest_improvements3
Thank you for reading and looking
cb147c1%40googlegroups.com?utm_medium=email_source=footer>
> >>> .
> >>> For more options, visit https://groups.google.com/d/optout.
> >>>
> >> --
> >> 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/ms
> >> gid/elixir-lang-core/CAK-y3CvWfMhgLqAVp5cncYVidxWOL9QMiH5qiL
> >> DoCOeB-YOqww%40mail.gmail.com
> >> <https://groups.google.com/d/msgid/elixir-lang-core/CAK-y3CvWfMhgLqAVp5cncYVidxWOL9QMiH5qiLDoCOeB-YOqww%40mail.gmail.com?utm_medium=email_source=footer>
> >> .
> >>
> >> For more options, visit https://groups.google.com/d/optout.
> >>
> >
> > --
> > 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/CAAO6v52jgCn0JbYoAu2jssq4Zf9M5
> > BgKvuJyzgguXr5wwtWhNw%40mail.gmail.com
> > <https://groups.google.com/d/msgid/elixir-lang-core/CAAO6v52jgCn0JbYoAu2jssq4Zf9M5BgKvuJyzgguXr5wwtWhNw%40mail.gmail.com?utm_medium=email_source=footer>
> > .
> > For more options, visit https://groups.google.com/d/optout.
> >
>
--
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/20180909030806.51f20270.eksperimental%40autistici.org.
For more options, visit https://groups.google.com/d/optout.
we
> would have Task.start_link/1,3, which is not handled by 1-3. :)
>
>
> *José Valim*
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Director of R
>
>
> On Sat, Oct 20, 2018 at 4:13 AM eksperimental
> wrote:
>
> > Thanks for bring this up
"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/20181020090639.3d881d02.eks
Thanks for bring this up, as I thought the same way.
Also we need to add support for this in ExDoc.
I'm all for using ",".
I have also found myself using Mod.fun/1-3
when refering to functions with default arguments.
I find it cleaner than using commas when referring to the same function with
`.
And implementation can be found in
https://github.com/eksperimental/elixir/tree/list_ends_with
What do you think about adding it?
--
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
web visit
https://groups.google.com/d/msgid/elixir-lang-core/20181231195201.1b3d1c08.eksperimental%40autistici.org.
For more options, visit https://groups.google.com/d/optout.
; 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/20181231202127.14b05f14.eksperimental%40autistici.org.
For more opt
I would like to propose the renaming of Enum.split_with/2 to Enum.split_by/2,
as it doesn't follow the naming rationale we currently have.
Taken from
https://github.com/eksperimental/elixir_inconsistencies#elixir-inconsistencies
Affected: Enum.split_with/2.
Proposed: Enum.split_by/2
-lang-core/20190116000134.15e73be0.eksperimental%40autistici.org.
For more options, visit https://groups.google.com/d/optout.
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Director of R
>
>
> On Tue, Jan 15, 2019 at 6:01 PM eksperimental
> wrote:
>
> > Hi list,
> > Reviewing the code from the File module,
> > made me wonder this if there is a reason while File.cp_r
to know if there's interest in such a
feature
thank you for your feedback,
- Eksperimental
--
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
> people using unless/else deserve to have their code broken...
>
>
> On January 3, 2019 at 4:57:17 PM, eksperimental (eksperimen...@autistici.org)
> wrote:
>
> On Fri, 4 Jan 2019 07:54:44 +0700
> eksperimental wrote:
>
> > On Thu, 3 Jan 2019 11:25:13 -0800
>
the suffixes in isolation. That would be an
> >> unnatural way to organize the API. How "_with" is used in start_with? is a
> >> different meaning than split_with which is marked by the preceding verbs.
> >> So unless the preceding word is also in the same cat
-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/20190104075444.30c1e2d7.eksperimental%40autistici.org.
For more options, visit https://groups.google.com/d/optout.
On Fri, 4 Jan 2019 07:54:44 +0700
eksperimental wrote:
> On Thu, 3 Jan 2019 11:25:13 -0800
> Ryan Winchester wrote:
> > Have the formatter change it to an if/else , or just leave it for tools
> > like Credo to yell at you for an unless/else.
>
> This is definitely
>>> 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/2bb429a8-e583-48c1-a335-8660c115b24f%40googlegroups.com
> >>> <https://groups.google.com/d/msgid/elixir-lang-core/2bb429a8-e583-48c1-a335-8660c115b24f%40googlegroups.com?utm_medium=email_source=footer>
> >>> .
> >>> For more options, visit https://groups.google.com/d/optout.
> >>>
> >> --
> >>
> >> Andrea Leopardi
> >> an.leopa...@gmail.com
> >>
> >> --
> >> 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/CAM9Rf%2BJEN7vuwxxZFkrB8NytCCaSPAKtroMeA1sqe91n5SoFXg%40mail.gmail.com
> >> <https://groups.google.com/d/msgid/elixir-lang-core/CAM9Rf%2BJEN7vuwxxZFkrB8NytCCaSPAKtroMeA1sqe91n5SoFXg%40mail.gmail.com?utm_medium=email_source=footer>
> >> .
> >> For more options, visit https://groups.google.com/d/optout.
> >>
> >
> >
> > --
> >
> > Regards,
> > Bruce Tate
> > CEO
> >
> >
> > <https://bowtie.mailbutler.io/tracking/hit/f8218219-d2a8-4de4-9fef-1cdde6e723f6/c7c97460-016e-45fb-a4ab-0a70318c7b97>
> >
> > Groxio, LLC.
> > 512.799.9366
> > br...@grox.io
> > grox.io
> >
> > --
> > 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/CAFXvW-65ztTOMoVhZ407PghmYA0OBcuVhDatcjYx6Xw7f52pMQ%40mail.gmail.com
> > <https://groups.google.com/d/msgid/elixir-lang-core/CAFXvW-65ztTOMoVhZ407PghmYA0OBcuVhDatcjYx6Xw7f52pMQ%40mail.gmail.com?utm_medium=email_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/702CFF39-BCFF-416F-BF28-81A5E1516903%40chrismccord.com
> > <https://groups.google.com/d/msgid/elixir-lang-core/702CFF39-BCFF-416F-BF28-81A5E1516903%40chrismccord.com?utm_medium=email_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/20190731104042.1b6a2fb4.eksperimental%40autistici.org.
The problem that I have with "frequencies" is that it means RATE over a PERIOD
of time or some
other unit.
I like the move to a function name that uses nouns, instead of verbs.
I think we should speak more of "repetition", "recurrence" or "occurrences",
"instances"
my two cents
On Fri, 18 Oct
> Currently we have different ways to display errors or warnings during
> compile time, we should normalize the output.
I would say currently there is one way to displays errors and one way to
display warnings.
I think it is important to keep different formats to visually differentiate
them
Enum.group_count/2 would be a name that describe better what this function does
IMO, but it
wouldn't work as Enum.group_by/3 since this one groups by key, and group_count
would group by
elements ({key, value})
On Sun, 6 Oct 2019 01:09:06 +0700
eksperimental wrote:
> The problem I h
This will work:
defguard to_boolean(term) when term not in [false, nil]
On Wed, 23 Dec 2020 15:02:43 -0500
Austin Ziegler wrote:
> It would be easy enough to provide this as a predicate in your own
> code if that’s your style preference
>
> ```elixir
> def boolean(falsy) when falsy in
On Thu, 3 Dec 2020 19:06:18 -0500
Allen Madsen wrote:
> Enum.compare_count([], 1) #=> :lt
> Enum.compare_count([1], 1) #=> :eq
> Enum.compare_count([1, 2], 1) #=> :gt
This is the way to go, because in one function call we can determine the
course of the action, such as in
case
Looking back, I think having acc as the first argument would be have a
better choice. But we have other functions named after "fold" such as
List.foldl/3, List.foldr/3, Inspect.Algebra.fold_doc/2 that take a
function in the same format as Enum.reduce/3. So having some
fold functions that take a
It happens that when I want to update a project that has been created
with an Elixir version prior to the introduction of the formatter,
I need to manually copy a .formatter.exs file. So I need to create a
new project and copy this file manually.
What I propose is to add an option called
On Mon, 21 Dec 2020 22:37:53 -0500
eksperimental wrote:
> Hi list,
> I would like to propose to convert two existing functions to guards in
> the MapSet module.
>
> 1. Is MapSet.size/1. I found myself not being able to use this
> function in guards, and having to port my c
Hi list,
I would like to propose to convert two existing functions to guards in
the MapSet module.
1. Is MapSet.size/1. I found myself not being able to use this function
in guards, and having to port my code, unless I want to get into
the bad habit of reading the internal structure of the struct
Adding Xavier's explanation to the documentation would be of great
help, and easier to spot if they are contained in its own section.
On Thu, 21 Jan 2021 14:28:00 +
Mário Guimarães wrote:
> I totally agree with Xavier.
>
> A qui, 21/01/2021, 13:33, Xavier Noria escreveu:
>
> > To me,
This version would be more idiomatic:
`not Enum.empty?(enumerable) and Enum.all?(enumerable, &(&1 == :some))`
If were were to choose a name for the new functions I would go with
`Enum.every_one?(enumerable, fun)`
On Thu, 21 Jan 2021 07:04:43 +
Anil Kulkarni wrote:
> Given that the
The use-case is totally fair. I would not consider it an edge-case.
+1 for adding the `on_empty: boolean` option
On Thu, 21 Jan 2021 10:00:02 -0300
Randson wrote:
> Yeah, I agree with you guys. The words are synonyms and I think we
> can add an option to all?/2, where default for breaking
`Mix.install(:decimal)` should also work out of the box IMO.
On Thu, 21 Jan 2021 03:18:44 -0800 (PST)
"woj...@wojtekmach.pl" wrote:
> A minor addition: I'd like to add a shortcut so you can write
> `Mix.install([:decimal])` instead of `Mix.install([{:decimal, ">=
> 0.0.0"}])`.
>
> > The
Thank you José and Michal for your input.
I will write a benchmark then and see if there is room for improvement.
On Thu, 14 Jan 2021 09:45:51 +0100
José Valim wrote:
> Eksperimental, it is faster to build a list and call maps:from_list/1
> than build the map as we go forward.
>
>
usability of
> Elixir on map transformation.
>
> A different question: how can we make these rich Erlang functions
> much more visible to Elixir users like myself? I don’t care that the
> arguments are “backwards” from the pipeline, because `maps:map/2` is
> _incredibly_ useful and
me it will be Protocol + Impl name.
>
>
> On Thu, Jan 14, 2021 at 4:38 AM eksperimental
> wrote:
>
> > I am working on a protocol, and I need to have access to the module
> > that implements the protocol. For example, `Enumerable.List`.
> >
> > It is actu
This protocol has some behaviour callbacks, one of them is `empty/0`. So
I cannot do MyProtocol.impl_for(term) because in that callback there is
no term (I am returning a term though).
https://github.com/eksperimental/buildable/blob/a2aa7658e58820472f56e7b1b7e3b3e2293c7950/lib/buildable
I am working on a protocol, and I need to have access to the module
that implements the protocol. For example, `Enumerable.List`.
It is actually mentioned in the documentation, but I would like to know
whether this is an implementation detail or a non-documented standard
that I can rely on. In
Great finding.
Regardless the benchmarks, Map.new/2 should be optimized for maps using
:maps.map/2, because as of now we are doing: map |> Enum.to_list() |>
reduce list |> :lists.reverse() |> :maps.from_list()
On Tue, 12 Jan 2021 14:09:26 -0800 (PST)
"jonar...@gmail.com" wrote:
> This usage of
p, key, value)
end)
end
It would be interesting to see how that benchmarks against :maps.map/2
when enumerable is a map.
On Wed, 13 Jan 2021 14:49:59 -0500
eksperimental wrote:
> Great finding.
> Regardless the benchmarks, Map.new/2 should be optimized for maps
> using :maps
On Mon, 5 Apr 2021 09:48:21 -0400
Allen Madsen wrote:
> @spec foo(1) :: "one"
> @spec foo(2) :: "two"
> def foo(1), do: "one"
> def foo(2), do: "two"
Yes, but those would not be duplicated.
These would, and Dialyzer will error saying that "foo/1 has overlapping
domains"
@spec foo(1) :: "one"
Hi,
I would like to propose that the compiler emits a warning when specs
are duplicated.
defmodule DuplicatedSpecs do
@spec foo(arg) :: {:ok, arg} when arg: term
@spec foo(arg) :: {:ok, arg} when arg: term
def foo(term), do: {:ok, term}
end
The reason is that the duplicated line should
On Mon, 5 Apr 2021 09:43:39 +0200
José Valim wrote:
> This is most likely the job of Dialyzer and tools working on
> typespecs to do. As they can do a better job at that.
There are cases where specs may be used for documentation purposes
only, and Dialyzer may not ever been run.
I actually
On Sat, 13 Mar 2021 04:26:41 -0800 (PST)
Igor Silva wrote:
> Current behavior
>
> case ?a do
> x when x in ?a..?z -> # code
> x when x in ?A..?Z -> # code
> _ -> # code
> end
>
> Desired behavior
>
> case ?a do
> ?a..?z -> # code
> ?A..?Z -> # code
> _ -> # code
> end
>
>
> 1. x..y and x..y..z won't be allowed in patterns (you will have to
> match on %Range{})
José, wouldn't this be a backward incompatible introduction? Even if we
still soft deprecated and emit a warning, there could be a lot of
changes to do, since this is not just a function call that needs to
On Mon, 22 Mar 2021 14:09:17 +0100
José Valim wrote:
> > José, wouldn't this be a backward incompatible introduction?
>
> All code written today will still work. However, if you use the new
> features (empty ranges or custom steps), then old code may not
> process the range accordingly. So it
On Mon, 22 Mar 2021 08:10:29 -0500
Amos King - Binary Noggin wrote:
> I like the proposals using a different operator for the step.
> `a..b\\c`?
+1 on this one. Visually it is less confusing to have
`1..100\\2`
than to have
`1..100..2`
as it is easier to identify the range part, plus it keeps
> Benchmark results.
> - map:
> https://gist.github.com/eksperimental/77d5c67427fed0a8a9e7eee21219febb
> - keyword:
> https://gist.github.com/eksperimental/1bac29e80fd8329940be2cc8e6b86d52
>
> This is the repository for the benchmarks
> https://github.com/eksperimental/
o).
The results took me by surprise for Maps.
Benchmark results.
- map:
https://gist.github.com/eksperimental/77d5c67427fed0a8a9e7eee21219febb
- keyword:
https://gist.github.com/eksperimental/1bac29e80fd8329940be2cc8e6b86d52
This is the repository for the benchmarks
https://github.com/eksp
I have noticed that there are times that based on the get value, there
is no need to update the data, and we have just to pass the same data
back.
So in addition to `:pop` I propose to add `:keep` or `:skip`.
This will optimize things quiet a not only in {Map,
Keyword}.get_and_update/3 but aslo
It is documented.
> If successful, returns a tuple in the form of `{integer,
> remainder_of_binary}`.
The spec could be improved to reflect this though
On Mon, 8 Mar 2021 10:13:29 -0500
eksperimental wrote:
> It is not documented,
> but it does not trim your string, what is does
It is not documented,
but it does not trim your string, what is does is to parse the first
integers it finds, and returns the remainder of the string as the
second element of the tuple.
iex> Integer.parse("2ABC")
{2, "ABC"}
On Mon, 8 Mar 2021 07:04:54 -0800 (PST)
Izzy Elwyn wrote:
> Hello,
Hi all,
Since documentation is taken seriously in Elixir,
I would like to propose to emit a warning when a public function
does not a have a proper/complete function signature.
I describe an improper fucntion signature would look like this in your
IEx/ExDoc documenation:
{:error, _reason} = error -> {error}
> >>> end
> >>> end
> >>>
> >>> Even if it did, it's not doing a great job of communicating the
> >>> intent and still potentially requires a Enum.reverse call. The
> >>> intent here is "early e
Not necessarily that they are replaceable,
but that pattern of :cont, :halt, :suspend is most commonly used via
Enumerable.reduce
On Mon, 20 Dec 2021 19:18:53 -0500
"'eksperimental' via elixir-lang-core"
wrote:
> > I have found only one usage of Enum.reduce_while in Elixi
On Tue, 21 Dec 2021 14:03:49 +0100
José Valim wrote:
> 2. By declaring the variables that are part of reduce prior to the
> generators, they can be used as part of the filters. So we can further
> change the code above to this:
So, the reduce() and let() part is going to be accepted only at the
useful and they are always enabled. Or they are not always useful and
> therefore it should not be the responsibility of the compiler to
> enforce it.
>
> On Mon, Dec 20, 2021 at 2:31 PM 'eksperimental' via elixir-lang-core <
> elixir-lang-core@googlegroups.com> wrote:
>
> > That is
ing useful for libraries, I think it is a
> > very strong imposition for applications and I don’t think it should
> > be the job of the compiler to enforce it.
> >
> > So my suggestion is to implement this as linter/credo check.
> >
> > On Sun, Dec 19, 2021
The proposal is very concise,
the only thing that would be problematic is the use of `reduce` for two
different things,
for <>, x in ?a..?z, reduce: %{} do
acc -> Map.update(acc, <>, 1, & &1 + 1)
end
{sum, count} =
for reduce({sum, count} = {0, 0}), i <- [1, 2, 3] do
sum = sum + i
t; Good point. I forgot to mention the :reduce option will be deprecated
> in the long term.
>
> On Mon, Dec 20, 2021 at 7:53 PM 'eksperimental' via elixir-lang-core <
> elixir-lang-core@googlegroups.com> wrote:
>
> > The proposal is very concise,
> > the only thin
Sorry, that was the issue.
This is the actual PR https://github.com/elixir-lang/elixir/pull/10354
On Fri, 19 Nov 2021 17:09:55 -0500
"'eksperimental' via elixir-lang-core"
wrote:
> Hi Marten,
> You will find this PR interesting
> https://github.com/elixir-lang/elixir/issue
Hi Marten,
You will find this PR interesting
https://github.com/elixir-lang/elixir/issues/10352
Cheers,
- Eks
On Fri, 19 Nov 2021 14:00:40 -0800 (PST)
"w...@resilia.nl" wrote:
> Hi all!
>
> I recently needed to check what fields for a struct were defined (if
> any) for a particular module, at
file and have to switch back and forth to make
sure of this.
I would like to focus on my module and know whether I can write invalid
doc tests or not.
Please let me know what you thing about this,
- Eksperimental
--
You received this message because you are subscribed to the Google Groups
1 + 1
> 2
>
> On Thursday, December 9, 2021 at 3:44:55 PM UTC+1 eksperimental wrote:
>
> > Hi list,
> > documenting functions made me realize the need to be able to disable
> > doctests per documentation entry. So I would like to propose the
> > addition
he test file, passing the
> > :exclude
> > or :only options to `doctest`, I find it inconvenient to define what
> > gets doctested in another file and have to switch back and forth to
> > make
> > sure of this.
> > I would like to focus on my module and know whet
When starting to work in this implementation was wondering what should
be the return value of
String.trim_leading("--__--abc", [" ", "-", "_"])
and I realized that it should mimic String.replace_leading/3
Therefore it should returning "abc"
Which leads me to think we should introduce
to the behaviour of trim_leading/1 and trim_trailing/1). So we
> could add trim_prefix/2 and trim_suffix/2, but then it is
> inconsistent with other trim* functions. So unless there is a strong
> reason for adding this, rather than consistency, I would not go this
> route.
>
&
place equivalents. Shall we go this route for
> now? Please open up an issue and feel free to submit a PR. :)
>
> I am not convinced on trim_prefix/trim_suffix yet though, but you can
> use the replace functions to achieve the same.
>
> On Wed, Mar 2, 2022 at 7:11 PM 'eksperiment
We already have List.last/1-2
On Thu, 24 Mar 2022 06:24:24 -0700 (PDT)
Weslei Juan Novaes Pereira wrote:
> As Elixir has the `hd` and `tl` functions, it'd be very useful to
> have a `init` and `last` functions as well. For example:
>
> last: takes a list and returns its last element.
> iex>
It totally slipped my mind.
I will update the docs to make this more noticeable,
as of now if you look for "skip" the only relevant information is for
skipping tests, not modules or describe blocks.
Thank you Wojtek,
On Thu, 03 Feb 2022 15:50:49 +0100
Wojtek Mach wrote:
> This is already
Currently `@tag :skip` is only effictive in tests, but if I have a
describe block with 10 test, i need to add the tag to each one
individually.
So I propose for the describe blocks to support the skip tag to ease
development testing.
--
You received this message because you are
Hello everyone,
Currently the second argument of funtions String.{trim, trim_leading,
trim_trailing}/2 can only be a string.
I would like Elixir to support a list of strings to be trimmed, such as:
String.trim_leading(tag_name, ["OTP_", "OTP-"])
There is a precedent of other functions
On Tue, 25 Jan 2022 18:33:08 +0100
José Valim wrote:
> Yes, I think those would be consistent additions!
>
I will try to submit a PR this week then.
--
You received this message because you are subscribed to the Google Groups
"elixir-lang-core" group.
To unsubscribe from this group and stop
1 - 100 of 111 matches
Mail list logo
