great.
On Thursday, May 26, 2016 at 11:11:16 AM UTC-4, Myron Marston wrote:
>
> Maybe we could submit PRs to Erlang/OTP itself to improve the error
> messages. That way, it helps Erlang developers and helps us :).
>
> Myron
>
> On Thursday, May 26, 2016 at 4:53:55 AM UT
Your example implementation shows why this isn't really necessary. Moreover
it doesn't compose well. Consider:
map
|> Enum.filter(fn {k, v} -> key_filter(k) && value_filter(v) end)
|> Map.new
vs
map
|> Map.filter_keys(key_filter)
|> Map.filter_values(value_filter)
In the latter it starts as a
http://nerves-project.org/ Enjoy :)
On Monday, May 9, 2016 at 12:36:45 PM UTC-4, Ed Wildgoose wrote:
>
> On 05/05/2016 17:44, w.m.w...@student.rug.nl wrote:
>
> > - when included in the stdlib, compiling/usin Elixir on embedded devices
> becomes impossible because of the increased file size.
The title is a bit misleading as it implies that Elixir doesn't have `fn ->
"yo" end`, but at least that's cleared up in the body.
I do think it can be useful, IE `Task.async((args))` is more succinct
than `Task.async(fn -> foo(args) end)`. Spawning processes and the like are
about the only
See an earlier discussion on a similar
idea: https://groups.google.com/forum/#!topic/elixir-lang-core/eE_mMWKdVYY
On Friday, January 20, 2017 at 3:12:37 PM UTC-5, Paul Schoenfelder wrote:
>
> Sorry Josh, I should have replied to your original proposal. What I was
> getting at is that you can
Here's the thing. Right now import doesn't require any special syntax. It's
data driven, and uses elixir structures that already exist and are usable.
Every single option you listed requires changes to the parser, new language
constructs or both. All to do exactly what we can right now. I don't
You necro'ed a thread that was effectively a year old, it isn't an ideal
place to receive feedback.
Maybe try posting on the elixir forum?
On Sunday, August 28, 2016 at 1:13:55 PM UTC-4, Hassan Zamani wrote:
>
> No comments?
>
> On Saturday, August 13, 2016 at 2:53:56 PM UTC+4:30, Hassan Zamani
your feedback. Always interesting to build up a body of
>> knowledge about how the community thinks about a particular subject.
>>
>> @eric: Why do you think they are both imperative, and how would you make
>> them more declarative? Very interested!
>>
>> Ch
The documentation is pretty thorough
here: http://elixir-lang.org/docs/master/elixir/Kernel.html#use/2
Honestly, use isn't really beginner material. What do you mean by "start
using module that he himself wrote" ?
On Tuesday, November 22, 2016 at 6:54:32 PM UTC-5, Razvan Musetescu wrote:
>
>
FWIW I have renamed a couple enormous projects and in all cases it took
basically 2 find and replace runs and a folder move.
--
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,
Can you elaborate on the code you have in mind? This sounds like a general
characteristic of pipes and not something specific to Map.get_lazy.
On Monday, March 20, 2017 at 6:48:46 AM UTC-4, David Long wrote:
>
> That's not entirely accurate. In my case I was using a series of pipes so
> I did
Agreed. Inspect can leak sensitive information easily, and I think it's
important to annotate that a structure will be using its debug
representation in a string.
On Sunday, July 30, 2017 at 3:31:57 AM UTC-4, José Valim wrote:
>
> I personally prefer the clearer approach of calling "inspect"
This has been proposed before, and it was rejected then as well. You're
only saving a few characters, and it obfuscates that two completely
different things are happening (assignment, function calling).
On Friday, May 19, 2017 at 1:27:29 PM UTC-4, OvermindDL1 wrote:
>
> Actually that specific
Setting aside whether or not the existing functionality is intuitive or
not, this isn't actually a proposal. You aren't suggesting an alternative.
On Thursday, September 21, 2017 at 10:17:12 AM UTC-4, Krzysztof Wende wrote:
>
> Right now when we import a module A
>
> defmodule CurrentA do
>
No, there is intentionally no way to globally apply a macro.
On Saturday, September 30, 2017 at 7:42:54 AM UTC-4, gasp...@gmail.com
wrote:
>
>
>
> On Saturday, September 30, 2017 at 2:36:30 PM UTC+3, Louis Pilfold wrote:
>>
>> Heya
>>
>> You could write a library that does this rather than
Have you evaluated an Agent for your purposes? It has basically exactly
this function.
On Tuesday, January 30, 2018 at 9:17:08 AM UTC-5, Federico Bergero wrote:
>
> Hi all,
> I'm proposing a new GenServer callback `query` similar to the
> call but which does not change the process
This is achievable with `\` btw:
with \
%{x: x} <- y
do
x
end
On Tuesday, January 30, 2018 at 7:39:07 AM UTC-5, Po Chen wrote:
>
> Ah I thought `with` was part of the language, then I realized how small
> the language core is.
> Now I wish the language is actually a little bigger :S mixed
I too would find this useful.
On Wednesday, February 14, 2018 at 2:19:04 PM UTC-5, pragdave wrote:
>
> ✓
>
> On Thursday, January 18, 2018 at 9:09:32 AM UTC-6, Ville Hellman wrote:
>>
>> Hey all,
>>
>> I'm proposing a new option for the `mix new` task: `--nocomments` when
>> run with this
Can you elaborate on the safety provided by doing `%Struct{} = ` on a
function? There are no compile time checks that calls to that function are
actually of that struct type, just runtime checks on the data. Put another
way this isn't really a type check, but an assertion.
On Friday, February
Can you elaborate on motivating code patterns? Every instance where I've
wanted to determine if a specific module is around has been a compile time
question for meta-programming purposes, and the `Code.ensure_loaded?`
function has worked great for that.
On Sunday, February 25, 2018 at 6:56:25
The downside here is that you can no longer copy and paste the output.
On Monday, January 1, 2018 at 10:58:30 AM UTC-5, Wojtek Mach wrote:
>
> Hello,
>
> Having an Inspect implementation would make a shorter output in iex,
> exunit diffs etc and the string representation is inambiguous. Under
An important thing to note is that in Elixir it's generally the caller of a
function that determines whether they want sync or async behaviour, not
the callee. Generally speaking you simply write functions that take input
and return output. If a given caller of that function wants that to
I would highly recommend taking a walk through existing threads in the
mailing list and forums. This and other similar pipe additions have been
requested before. I'm glad you're interested in improving the language, but
the proposal itself doesn't reflect a familiarity with existing answers to
maybe(t) is traditionally `Some(t) | None`, which isn't really the same as
`nil | t`. The closest analogue would seem to me to be `{:ok, t} | :error`
although that doesn't quite communicate the same thing.
On Tuesday, February 27, 2018 at 7:11:39 AM UTC-5, Yordis Prieto wrote:
>
> Introducing
Is nillable(String.t) less boilerplate than String.t | nil ?
On Wednesday, February 28, 2018 at 9:12:42 AM UTC-5, Yordis Prieto wrote:
>
> I am more interested on the solution of `nil | t` I dont mind changing the
> name to `nillable(t)` or whichever other word in English.
>
> The needs come
I don't really agree that it makes the intent clearer. It combines two
distinct and unrelated activities. One takes the sum of a list, the other
maps each value in a list to some other value. list |> Enum.map(& &1 * 2)
|> Enum.sum expresses this perfectly. If you're going for lolspeed and need
Can you elaborate for those of us with less context? What is tree-sitter?
What are you proposing?
On Thursday, March 28, 2019 at 10:10:14 PM UTC-4, João Paulo Silva de Souza
wrote:
>
> Seems like I wrongly opened an issue instead of posting here first ->
>
Ideally,
> if possible, we can use a property-based test to validate that inverting
> the map 2 times will always returns the initial map.
>
> What are your thoughts?
>
> Thanks,
>
> Justin
>
>
> On Thursday, February 7, 2019 at 5:45:49 AM UTC-7, Andrea Leopar
Map.invert is at least largely harmless, unlike some of the other proposals
that happen. It's still a little odd to me to have a function that boils
down to just:
Map.new(map, fn {k, v} -> {v, k} end)
Honestly that is almost clearer if you've never heard the word "invert"
with respect to
I think having Enum.filter(list, /1) actually reads
pretty well. It avoids the issue with putting it in Kernel, and provides a
very explicit name which speaks to Bruce's goal of naming concepts.
On Tuesday, July 30, 2019 at 12:47:08 PM UTC-4, Allen Madsen wrote:
>
> I don't have a strong
The presence of rarely used functions is not an argument for the addition
of further rarely used functions.
On Wednesday, July 24, 2019 at 1:05:59 PM UTC-4, Mário Guimarães wrote:
>
> It seems this function was proposed here
> https://github.com/elixir-lang/elixir/pull/5917
>
> and dropped
This function is really good as an exercise for new programmers to
implement, for sure. In terms of regular workflows, how often does this
exact function really come up? Given that it's only three lines to
implement, I'm not sure that adding it to the standard library contributes
much towards
I really like this feature idea. Often you don't know or expect that a
particular function will take so long, and it's precisely at that point
that you go "man, I wish I had timed that". Particularly if the function is
doing a side effect, it may be non trivial to try again.
Perhaps if the
FWIW We have an earliest_date and latest_date helper in almost every Elixir
app we've built. The Enum.sort solution requires requires too many leaps to
be at a glance readable if it's been a bit since you used DateTime.compare.
Definitely a fan of including this.
On Thursday, October 10, 2019
ut. *
>
> -bt
>
>
>
> On Tue, Feb 4, 2020 at 8:58 AM Amos King > wrote:
>
>> Ben,
>>
>> That is how const is used in Haskell. Although without currying I don’t
>> see how it is useful. I’m waiting to see an example that drives it home. I
>> agr
I agree with Michal. Additionally, I'm not clear how `const/1` could be
used in Bruce's example at all.
To elaborate, `fn -> foo() end` and `const(foo())` cannot be equivalent
when `const/1` is merely a function. This becomes readily apparent when
`foo()` is side effects or side causes. In
,
because you could do:
```
Enum.map([1,2,3,4], (&1, :foo))
```
which would return `[:foo, :foo, :foo, :foo]` effectively replacing the
contents of the list with all `:foo`. Is that the idea?
On Tuesday, February 4, 2020 at 8:16:53 AM UTC-5, Ben Wilson wrote:
>
> I agree with Michal. Additio
Hi Adam,
I believe this functionality already exists in the form of this function
and others with the "chunk" name.
https://hexdocs.pm/elixir/Enum.html#chunk_every/2
- Ben
On Sunday, March 29, 2020 at 5:58:19 AM UTC-4, Adam Lancaster wrote:
>
> Hello,
>
> Elixir is great. The Enum module is
Hi Eric,
Whether or not this is functionally equivalent to split_with depends on how
it handles non unique lists, eg:
Enum.pop_by([1,2,2,3], fn x -> x == 2 end)
If it returns
{2, [1, 2, 3]}
Then it is definitely at least different.
This almost seems better suited for the List module. Map and
Perhaps you addressed this, but how would IO.error behave when not
compiling things? How would it behave if you remote console into a running
system and call IO.error?
On Monday, May 11, 2020 at 11:33:40 PM UTC-4, Dallin Osmun wrote:
>
> I understand at first glance this proposal might not seem
The issue is, those packages need to be compiled and in a specific order,
how would that work? `hex` isn't a build tool, `mix` is.
On Monday, June 15, 2020 at 6:07:49 AM UTC-4, Simon St.Laurent wrote:
>
> I would love to see (some version of) both the original proposal and this
> one. They
Unfortunately it cannot do this in all cases:
fun = /1
foo
|> tap(fun)
|> blah
`tap` as a macro has no ability to know whether `fun` is a function at
compile time.
On Friday, January 15, 2021 at 1:54:58 PM UTC-5 Allen Madsen wrote:
> I meant compile time.
>
> Allen Madsen
>
Right, and this is why I think Jose is arguing that this is a job for
Dialyzer. The only way to know that two specs are duplicate is if they are
logically duplicate. Elixir does not know about the logic of specs today,
that's dialyzer's job. eg:
@type one :: 1
@spec foo(1) :: "one"
@spec
The 1..9//2 structure feels like the best of the presented options to me. I
think it reads well out loud, since .. often means "to" and / is often
rendered as "by" so that would read 1 to 9 by 2.
To make sure I'm clear about the semantics: If I have:
```
1..x//1 |> Enum.to_list
```
Then if
I think eksperimental was dead on when he said what you really want is
`cond`.
```
cond do
val in ?a..?z
val in ?A..?Z
```
Changing `case` to have an implicit `where` in certain special cases is
going to make it behave inconsistently compared to other places that take
patterns. Optimizing the
Implemented this way, options like max_restarts max_children and so on
would occur per partition. I take it the plan would be to simply note that
in the docs? I don't see any easy way to enforce those values across all
partitions, which I think is just fine.
which_children/1 and so on won't
I believe this nicely addresses my concerns from the first proposal. Inner
refactoring into functions is 100% possible, and there are no strange
reassignment behaviors introduced that don't extend to the rest of the
language. As for the questions outlined in the guide:
1) To Paren or not
To revisit the example situation from the original post:
```
{sections, _acc} =
for let {section_counter, lesson_counter} = {1, 1}, section <- sections do
lesson_counter = if section["reset_lesson_position"], do: 1, else:
lesson_counter
{lessons, lesson_counter} = for let lesson_counter, lesson
I am with Louis and Paul so far I think. I won't repeat their comments but
I think I can extend the issue by pointing out that this breaks refactoring
for the inner contents of `for`. Previously, if you have:
```
for lesson <- section["lessons"], reduce: 0 do
counter ->
# complex
I would benchmark to make sure that you're actually gaining something. If
you are relying on it to be small, then at that specific size a list might
also just be fine, and you won't be relying on behavior that could change
in a future release.
On Monday, March 7, 2022 at 11:49:06 AM UTC-5 Max
Yup, I also see the value in a human check. I think it's analogous to `mix
format --checked` where the option explicitly exists to allow systems to
enforce expectations.
+1 from me.
On Friday, April 1, 2022 at 1:51:12 PM UTC-4 ma...@jonrowe.co.uk wrote:
> If I'm understanding the original
__MODULE__ is the right answer here IMHO. It is consistent with the other
"meta constants" like __ENV__, __DIR__ __FILE__ and so on in that they
desugar to constants, but are file / code relative. It isn't a super common
pattern, but last time I checked generated phoenix code does a
For that purpose, I feel like:
{:ok, %{pattern: [match, here]}} = Foo.await(item)
would work right? Can you help me understand why the patterns themselves
need to be passed to your `await` function?
On Monday, January 24, 2022 at 12:09:56 PM UTC-5 mateus...@swmansion.com
wrote:
> Hi there,
>
> Personally, I don't see the harm in supporting it. If someone's going to
abuse it, they'll abuse Enum.at()
The harm isn't for people who doing it intentionally, the harm is for
people who are doing it unintentionally. Index based array access is so
common in certain languages that it's one
> I'm sure there is the opinion that this is anti-pattern
Yup. Side stepping this a bit though and getting to something deeper: This
does not seem like it needs to be part of the standard library. You could
make a library called GenServerWithExceptions or something and put it up on
hex, and
> `Map.get(map, key, default_value)` looks better than `Map.get(map, key)
|| default_value`
This isn't a matter of looks, these have straight up different
functionality. You can't change this sort of thing in the language at this
point in its lifecycle. Plus, you'd be forcing everyone who's
I think it would be helpful to see examples of regular Elixir code today
that would be improved with this operator. The Plug example doesn't really
work for me because Plug is doing a bunch of compile time stuff anyway and
it also isn't using the pipe operator.
On Tuesday, October 25, 2022 at
Seems like a good opportunity for a library. There's not anything I'm
seeing there that would require changes to the core language. Building a
library is a good way to test out if it's a popular idea and work though
any of the design challenges.
On Sunday, September 4, 2022 at 3:52:04 PM UTC-4
To me this feels like a good use of credo or similar linter, not something
that the Elixir compiler itself should warn about. `assert %{} = x` isn't
the most idiomatic way to match but it isn't incoherent or invalid, just
probably not best practice.
On Tuesday, August 16, 2022 at 5:55:09 AM
> DateTime.compare(a, :<, b) would get my vote of the alternative proposals
but I think it doesn't move much the needle in comparison to
DateTime.compare.
To me this is a pretty big difference difference, because with an `import`
it does 2 things:
1) Eliminates the existence of an irrelevant,
Apologies, I missed that you addressed how `{1, 2, 3} |> pattern_filter({1,
a, b})` would work in your earlier reply, in that you only allow a single
variable to be bound. This further reduces its general applicability.
On Thursday, December 15, 2022 at 4:12:37 PM UTC-5 Ben Wilson wrote:
&
Hi Matt,
I am not on the core team nor do I speak for them. From what I have
generally seen, "alternative APIs" that can be implemented as libraries
generally should just stay libraries, unless there develops a strong
following that makes it clear that such an API should be moved into the
This seems reasonably straight forward to implement in your own code base:
```
def truncate(string, length, padding \\ ".") do
string
|> String.slice(0, length)
|> String.pad_trailing(String.length(string), padding)
end
```
Not seeing a strong need to include it in the standard library.
Making < and <= work in general for DateTime has been discussed and isn't
feasible. The macro answer I kinda love.
On Monday, October 31, 2022 at 3:42:16 PM UTC-4 m...@achempion.com wrote:
> Is it possible to modify language in a way to make >,<, = work for dates?
>
> The datetime's struct has
I'm generally +1 on this, but I am a tiny bit confused about the proposed
change to interpolation. Does this propose a change to interpolation for
all sigils, single or multi letter? If so, what is the deprecation plan for
the current interpolation syntaxx?
On Sunday, March 5, 2023 at 2:21:47
Agreed. Can the formatter get invoked on output like that I wonder?
On Friday, May 26, 2023 at 3:32:02 AM UTC-4 ifu...@gmail.com wrote:
> Consider the following code:
>
> setup do
> %{a: 1}
> end
>
> test "test", %{b: b} do
> IO.inspect(b)
> end
>
> if we run the test, then it fails with the
nction clause errors. :) If someone
> wants to explore this path, please go ahead!
>
> On Sun, May 28, 2023 at 5:13 PM Ben Wilson wrote:
>
>> Agreed. Can the formatter get invoked on output like that I wonder?
>>
>> On Friday, May 26, 2023 at 3:32:02 AM UTC-4 ifu
Hi,
This has been proposed before. Someone came up
with https://github.com/meyercm/shorter_maps which accomplishes this as a
macro. It might be worth a discussion again at this point but it is worth
noting that this is a proposal that has been on this list before, and so it
would likely be
Question: Would this sigil support interpolation? Is that too clever?
~URI"https://#{path}?#{query_params};
- Ben
On Thursday, May 18, 2023 at 1:37:37 AM UTC-4 christ...@gmail.com wrote:
> I dislike +1 posts, but I feel very strongly about this—it'd be amazing to
> have.
>
> I want booting an
69 matches
Mail list logo
