Re: [elixir-core:11878] Re: Short form of lambdas for zero arguments and unused arguments proposal

2024-08-23 Thread Ivan Yurov
Right. Sorry, please ignore the proposal to use &X to denote arity, the intent was to rather test the idea to be able to do that in general, not a particular syntax that would facilitate that. Using &/X might be a better candidate since it reflects the arity just the same way function capture does

Re: [elixir-core:11876] Re: Short form of lambdas for zero arguments and unused arguments proposal

2024-08-23 Thread Ivan Yurov
keep its usage rules clear > and this extension would violate that (in my opinion). > > On Fri, Aug 23, 2024 at 8:06 AM Ivan Yurov wrote: > >> The lambdas I want to be able to create using short notation are in the >> second block of code in the original posting. They are sli

Re: [elixir-core:11874] Re: Short form of lambdas for zero arguments and unused arguments proposal

2024-08-22 Thread Ivan Yurov
t; To unsubscribe from this topic, visit > https://groups.google.com/d/topic/elixir-lang-core/g2tQI1FjcNU/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > elixir-lang-core+unsubscr...@googlegroups.com. > To view this discussion on the web visit

[elixir-core:9084] Re: Enum.strain and Stream.strain

2019-08-23 Thread Ivan Yurov
This is what I created (and am using quite successfully for a while) for this matter: https://hexdocs.pm/monex/MonEx.html#content It kinda recreates the semantic of Result and Option type from Scala / Rust and others. On Tuesday, August 20, 2019 at 8:21:02 PM UTC-7, Spencer Carlson wrote: > > Gi

[elixir-core:8367] Re: Runtime typespecs assertion

2018-11-07 Thread Ivan Yurov
If you want type-safety why not to just pick a strongly typed language, like Ocaml for example? Elixir is bound to Erlang VM and will never provide any features like you're describing that are not supported by Erlang. And I don't think type-checking ever happens at runtime in any language. On W

Re: [elixir-core:8247] Re: Proposal: make Application.get_env being able to resolve {:system, var} tuple out of the box

2018-08-07 Thread Ivan Yurov
This is a great point that it would be pretty hard to pass anything but strings. And validation too. What still bothers me is that it might be pretty hard to keep track of settings if they are spread over config.exs and init simultaneously. I'll probably go with this Config module idea, thanks.

Re: [elixir-core:8245] Re: Proposal: make Application.get_env being able to resolve {:system, var} tuple out of the box

2018-08-06 Thread Ivan Yurov
tion env should be reserved for global config only. > > Just my two cents, > > Paul > > On Mon, Aug 6, 2018 at 5:33 PM Ivan Yurov > wrote: > >> I agree that in general this is not something that should be defined in >> the language core or the standard lib. >>

[elixir-core:8242] Re: Proposal: make Application.get_env being able to resolve {:system, var} tuple out of the box

2018-08-06 Thread Ivan Yurov
mmon for the > configs, that doesn't mean that someone really doesn't just want `{:system, > var}` returned straight though, as can be the case.. > > :-) > > > On Monday, August 6, 2018 at 1:15:08 PM UTC-6, Ivan Yurov wrote: >> >> While playing with dep

[elixir-core:8240] Proposal: make Application.get_env being able to resolve {:system, var} tuple out of the box

2018-08-06 Thread Ivan Yurov
While playing with deployment I found out that some libraries provide this feature that you can put {:system, var} in configuration and then it's resolved at runtime. However if it's in my code, I'd have to implement it on my own. Wouldn't it be nice if it was supported by Application module by