Re: [elixir-core:9414] Proposal: Closing the gap between configurations

[Dmitry Belyaev]

> Since "config/releases.exs" run only during releases, if you have a
syntax error (or similar), you will find about it just way too late

We solved this problem by setting dynamic runtime configuration ONLY in
"config/releases.exs" like so
config :my_app, base_url: URI.parse(System.fetch_env!("BASE_URL"))

And "dev.exs" sets some defaults and uses the same releases.exs to
configure applications:
[{"BASE_URL", "http://localhost"}]
|> Enum.each(fn {key, value} -> System.get_env(key) || System.put_env(key,
value) end)
import_config "releases.exs"

Of course, when used like that, it wouldn't affect the already started
applications which rely on configuration during the startup (as you mention
:kernel, :stdlib, :elixir and :mix).

However we don't import "releases.exs" in other environments:

* "prod" is only used for compilation on CI, so there's no need to load
dynamic runtime configuration, and it contains only production-grade
compile-time configuration and non-configurable runtime configuration;
* "test" contains its own set of settings completely separate from the rest
but it's possible to `import "prod.exs"` if that reduces repetitions.

So I suppose our usage of "releases.exs" is similar to what you are
proposing with "runtime.exs".

However I think using it unconditionally in every environment will only
complicate things, as you mention we'd have to branch on Mix.env/Config.env
- this seems more complex than our current approach.

> In the future we will deprecate Application.get_env/3 in the module body.

Does that mean during module compilation? I guess it'll still be available
in normal runtime?

As I understand "runtime.exs" is supposed to be simply copied to the
release.
Although it looks reasonably safe, I definitely wouldn't want to see some
testing or development settings in a file included in a release especially
if they are unused.


Maybe we should come to this problem from a different side.
What if we introduce a separate "compilation" stage (using separate set of
environments - e.g. dev_compile/prod_compile) and start a clean VM for the
real runtime after Mix compiled the applications?

Kind regards,
Dmitry Belyaev


On Thu, Mar 5, 2020 at 4:20 AM José Valim  wrote:

> Over the last releases we have been making improvements to the
> configuration system. However, there is still one large gap to be
> addressed. Today config files are treated as compile-time configuration by
> default. This behaviour, alongside overuse from libraries, made using the
> application environment via config files more rigid and error prone than
> they have to be.
>
> Today, Mix will load "config/config.exs" before any of the dependencies
> are compiled and on every command. This makes basic scenarios like the ones
> below impossible:
>
>-
>
>If your project requires some environment variables in development,
>you cannot enforce them. Otherwise, basic commands such as mix help or
>editor integration will stop working
>
>
>-
>
>If you need to configure one application based on another application,
>that is impossible to do as well, as no applications are available at this
>point
>
> Also, because configuration files run during compilation by default,
> library authors often accidentally rely on compile-time configuration.
> Luckily, Elixir v1.10 has added Application.compile_env/2. In the future
> we will deprecate Application.get_env/3 in the module body, which will
> help steer people to the correct direction in their own applications.
>
> On the opposite side, we have releases, where the configuration works at
> runtime only. Given there is no way to execute configuration at runtime in
> Mix, we end-up with two completely disjoint approaches. This introduces a
> couple issues of their own:
>
>-
>
>Since "config/releases.exs" run only during releases, if you have a
>syntax error (or similar), you will find about it just way too late
>
>
>-
>
>There is no way for frameworks like Phoenix to provide a configuration
>file that works for both Mix and release deployments
>
> Our goal is to address these issues. However, it is important to consider
> that a complex project today may already have many configuration files:
>
>- config/config.exs (compile time) - shared configuration settings
>- config/{dev,test,prod}.exs (compile time) - per env configuration
>settings
>- config/releases.exs (runtime) - release specific configuration
>settings
>
> Therefore, we would like to propose a new configuration file that can
> address the problem above while replacing the need to use
> "config/releas

Re: [elixir-core:9381] PROPOSAL: Nil-safe Access.at/1

[Dmitry Belyaev]

On 9 February 2020 12:18:05 pm AEDT, Greg Vaughn  wrote:
>... 
>The first step is to look for the equivalent of all the keys we care about and 
>create a map with known key names. Then we go through an Ecto changeset for 
>validation and further processing.

I think the problem is quite common and in my code every data type has a 
'from_json' function which takes the data for the embedded struct and calls 
that struct 'from_json' and so on.

With Ecto it is solved by just having a 'changeset' function in the struct 
module which uses Ecto.Changeset.cast and Ecto.Changeset.cast_embed which in 
turn loads the embedded struct.

>I look for, let's guess, about 15 fields from each of these json payloads. I'd 
>have to pattern match 15 times with an if statement,

So do you have 15 different paths now to handle different payloads? Will it be 
significantly better with nillable get_in?

All my code where I initially thought to use get_in/update_in, in the end I 
switched to direct struct pattern-matching/construction (for compile-time 
fields checks) and manual extraction of data using Map.get/3 (for more control).

I don't say that my way is any more convenient or better than any other. I'm 
just trying to suggest to look at the problem from scratch and try to apply 
some other solution -- maybe it will be reasonable without waiting for the 
standard library to be extended.

>
>-Greg Vaughn

-- 
Kind regards,
Dmitry Belyaev

-- 
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/FC20D8D4-1DDF-4673-AFE1-C8452113CAAC%40gmail.com.

Re: [elixir-core:9225] Re: [Proposal] latest and earliest functions for DateTime and NaiveDateTime

[Dmitry Belyaev]

I suppose it's reasonable to have a defined ordering within a particular class 
e.g. number class includes integers and floats, and have some (possibly 
undefined) ordering between classes. This basically is the same as Erlang term 
order, but for every struct we could define its own class or in some special 
cases a few structures would map to the same ordering class.

Then to make Erlang term ordering to work for us we can build a tuple {{class, 
class_ordering_term}, original_term}, e.g {{Number, 1}, 1}, {{DateTime, 
epoch_integer}, %DateTime{...}}, {{Atom, nil}, nil}.

On 18 October 2019 9:27:54 am AEDT, "José Valim" 
 wrote:
>> I do wonder about your follow-up: Why would it not work for integers?
>(and
>> float and decimals)? At least as long as we are comparing collections
>of
>> *only* integers or *only* floats or *only* decimals, the result would
>be
>> sensible.
>>
>If we want to make Ordered work between them, well, then it becomes a
>bit
>> more difficult: In that case we probably would need to 'upcast' all
>of them
>> into some kind of more general tuples-of-integers-and-strings form.
>>
>
>Exactly. That's the problem and at a quick glance I could not find a
>solution. I am glad to be proven wrong though!
>
>-- 
>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/CAGnRm4Kd_E_WMB0iKfR%3DoKGvK6Nq8MJVYVf8tsJ%3DP6vXX1ZT_Q%40mail.gmail.com.

-- 
Kind regards,
Dmitry Belyaev

-- 
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/CF75C266-8373-4461-AAED-6E8A2FAA9E8C%40gmail.com.

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

[Dmitry Belyaev]

So the perceived problem is that developers might be confused whether the 
timing is emitted by the entered expression or is provided by IEx.

One way that might help with that problem is consistency. If a developer always 
sees the timing, even when it's practically 0us, they don't need to guess 
whether it's genuine output or produced by IEx.

Another way is to display the timing of the previous expression *inside* the 
prompt, there should be no such confusion. Some repls also allow multiline 
prompts, and if its easy to identify their beginnings, there should be no 
confusion.

We could also extend the feature to provide some other details, e.g. number of 
messages in the process queue (as an advice to use flush), amount of memory 
needed to hold the produced value, and maybe something else.


On 18 October 2019 8:07:33 am AEDT, Fernando Tapia Rico  
wrote:
>I like the idea too, but I'm concerned about printing unexpected
>messages 
>in the REPL, users might not know where those messages are coming from.
>
>
>As an alternative, I would like to suggest adding a new IEx helper
>t/0,1 
>that would return the execution time of the previous command or the nth
>
>command (similar to v/0,1).
>
>
>On Thursday, October 17, 2019 at 10:10:49 PM UTC+2, José Valim wrote:
>>
>> I like this idea. A PR would be welcome. What should be the default 
>> trigger? 5s?
>>
>> On Wednesday, August 7, 2019 at 12:51:17 AM UTC+2, Exempll wrote:
>>>
>>>
>>>   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 retrospect. Something
>like 
>>> `[iex] OK time=4.1s` right before the next prompt. It wouldn't need
>to be 
>>> displayed for every command, but possibly just for the commands that
>pass a 
>>> certain running time threshold.
>>>
>>
>
>-- 
>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/9dc355ff-e59e-48a1-84e6-75f0e0151287%40googlegroups.com.

-- 
Kind regards,
Dmitry Belyaev

-- 
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/5BB42249-4817-4787-AEDB-531CB41D22F8%40gmail.com.

Re: [elixir-core:9104] Better error messages in Standard Library functions

[Dmitry Belyaev]

The error message is clear:
BracketPush.check_brackets makes a call to 
https://hexdocs.pm/elixir/String.html#replace/4 and passes empty string "" as 
the last argument instead of a list.

In dynamically typed languages we expect the caller to pass the correct data 
for the function to behave as documented. Imagine every function typechecked 
every argument to the deepest primitive types - the code would become an 
incomprehensible mess and performance would be terrible wth every function type 
checking the data in runtime which was already typechecked one level higher.

On 16 September 2019 7:50:56 am AEST, Landon Schropp  wrote:
>Hello!
>
>I'm new to Elixir development, so I'm approaching the language with
>fresh 
>eyes. One of the issues I've run into is difficulty understand the
>error 
>messages from the standard library. For example, today I ran this code:
>
>string
>|> String.replace(string, ~r/[^\[\](){}]/, "")
>|> IO.inspect(label: "\n")
>|> String.codepoints
>|> check_brackets([])
>
>When I run this code through one of my test cases, I get the following 
>error:
>
>  1) test math expression (BracketPushTest)
> test/bracket_push_test.exs:52
>  ** (FunctionClauseError) no function clause matching in Keyword.get/3
> The following arguments were given to Keyword.get/3:
>
>
> # 1   
>   
>""
>
>
> # 2
> :insert_replaced
>
>
> # 3
> nil
>   
>   
>   Attempted function clauses (showing 1 out of 1):
>
>
>def get(keywords, key, default) when is_list(keywords) and is_atom(
>key)
>
>
> code: assert BracketPush.check_brackets("(((185 + 223.85) * 15) - 
>543)/2") == true
> stacktrace:
>   (elixir) lib/keyword.ex:195: Keyword.get/3
>   (elixir) lib/string.ex:1372: String.replace/4
>(bracket_push) lib/bracket_push.ex:15: BracketPush.check_brackets/1
>   test/bracket_push_test.exs:53: (test)
>
> test/bracket_push_test.exs:52
>  ** (FunctionClauseError) no function clause matching in Keyword.get/3
> The following arguments were given to Keyword.get/3:
>
>
> # 1   
>   
>""
>
>
> # 2
> :insert_replaced
>
>
> # 3
> nil
>   
>   
>   Attempted function clauses (showing 1 out of 1):
>
>
>def get(keywords, key, default) when is_list(keywords) and is_atom(
>key)
>
>
> code: assert BracketPush.check_brackets("(((185 + 223.85) * 15) - 
>543)/2") == true
> stacktrace:
>   (elixir) lib/keyword.ex:195: Keyword.get/3
>   (elixir) lib/string.ex:1372: String.replace/4
>(bracket_push) lib/bracket_push.ex:15: BracketPush.check_brackets/1
>
>As a new language user, it's really hard to understand what I did wrong
>
>when the error is thrown from inside the inner implementation of 
>String.replace/4. In order to debug this, I'd either have to look at
>the 
>inner implementation of String.replace/4 or attempt to fiddle with the 
>arguments. My preference would be for standard library functions to
>guard 
>their own interfaces, and throw specific and actionable messages back
>to 
>the developer.
>
>Thanks for taking the time to read!
>
>-- 
>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/ec0892c5-04b8-4fe7-88b5-e12312483fa6%40googlegroups.com.

-- 
Kind regards,
Dmitry Belyaev

-- 
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/03040498-4D0B-4DAE-B8FC-11317F6210CE%40gmail.com.

Re: [elixir-core:9099] [Proposal] Add ability to parse ISO8601 "basic" format

[Dmitry Belyaev]

Getting a value from a keyword definitely costs more then having that value 
supplied directly as a positional argument. Of course the cost is very small, 
but why waste when we have a way which doesn't waste.

I suggest a separate function `from_iso8601_short`.

On 9 September 2019 10:07:39 am AEST, Kelvin Raffael Stinghen 
 wrote:
>> Another idea is to deprecate `Date.from_iso8601(string, calendar)` in
>favour of `Date.from_iso8601(string, calendar: calendar)`, and then
>`:format` becomes just another option.
>
>I’m +1 for this one. For optional parameters it is always good what
>actually that’s optional that it receives. I would even deprecate every
>`Date.something(date, calendar)` call in favor of that.
>
>Best,
>Kelvin Stinghen
>kelvin.sting...@me.com
>
>> On Sep 7, 2019, at 10:10, Wojtek Mach  wrote:
>> 
>> Another idea is to deprecate `Date.from_iso8601(string, calendar)` in
>favour of `Date.from_iso8601(string, calendar: calendar)`, and then
>`:format` becomes just another option.
>
>-- 
>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/C101F06D-C6B7-4025-B722-78AD34906203%40gmail.com.

-- 
Kind regards,
Dmitry Belyaev

-- 
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/DECB2A72-9D8E-45A7-BF0A-2FA52B7D9887%40gmail.com.

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

[Dmitry Belyaev]

I think of & as those in that order of preference:
&/ - local function reference
& - lambda definition
where  :  |  | ()

So
&1 = fn -> 1 end
/2 = fn a, b -> num(a, b) end

And of course we don't need even the existing syntax as "this would be done to 
save just a handful of characters".



On 15 February 2019 22:10:04 GMT+11:00, "José Valim" 
 wrote:
>Furthermore there are intrinsic ambiguities:
>
>For example:
>
>&1
>
>
>Is that a function that returns 1 or is it a user error which forgot
>the
>outermost &?
>
>And this example:
>
>/2
>
>
>Is that num divided by 2 or an attempt to capture the num function of
>arity
>2?
>
>So the reason why the capture operator requires at least one
>(consecutive)
>argument is to make the code clearer. And sure, the compiler could
>solve
>those, but the ambiguity will always be there for users reading the
>code.
>
>*José Valim*
>www.plataformatec.com.br
>Skype: jv.ptec
>Founder and Director of R
>
>
>On Fri, Feb 15, 2019 at 12:05 PM Andrea Leopardi
>
>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 just a
>handful
>> of characters.
>>
>> Andrea
>>
>> On Fri, 15 Feb 2019 at 11:56, Mário Guimarães <
>> mario.luis.guimar...@gmail.com> wrote:
>>
>>> 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 captures without the need for any
>>>> argument, so that of instead of writing
>>>>
>>>> fn () -> M.fun("value")
>>>>
>>>> end one could write
>>>>
>>>>
>>>> ("value")
>>>>
>>>> Today the later returns an error like
>>>>
>>>> ** (CompileError) iex:28: invalid args for &, expected an
>expression in
>>>> the format of /arity, /arity or a capture containing
>at
>>>> least one argument as &1, got: M.fun("value"))
>>>>
>>>> Thanks
>>>> Mário
>>>>
>>> --
>>> 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/a8c88a03-3a3a-4161-bbe4-52f24e1592e9%40googlegroups.com
>>>
><https://groups.google.com/d/msgid/elixir-lang-core/a8c88a03-3a3a-4161-bbe4-52f24e1592e9%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%2BKJDRioz6hpw5-_ByvTNeTd8X-ecMFFXJyJrSsnzi4PXQ%40mail.gmail.com
>>
><https://groups.google.com/d/msgid/elixir-lang-core/CAM9Rf%2BKJDRioz6hpw5-_ByvTNeTd8X-ecMFFXJyJrSsnzi4PXQ%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/CAGnRm4%2B6g5ZBCVyKT_o-O7eeHrG0RetNy64%2BxSN_k8QXTv4Duw%40mail.gmail.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
Kind regards,
Dmitry Belyaev

-- 
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/9C3AFE2E-6DF0-42E3-89D0-1CD5D3726E71%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:8473] [Proposal] Add invert() method to Map module

[Dmitry Belyaev]

2/Hash.html#method-i-invert
>>>
>>> Recently I wanted to invert a map in one of my Elixir programs
>(details 
>>> below), and I googled and found the below solution by Chris McCord
>in h
>>>
>ttps://stackoverflow.com/questions/26614682/how-to-change-all-the-values-in-an-elixir-map
>>> :
>>>
>>> def invert(map) when is_map(map) do
>>> for {k, v} <- map, into: %{}, do: {v, k}
>>>   end
>>>
>>> I would basically like the above function to be added to the
>Elixir.Map 
>>> module.
>>>
>>> Here is the scenario for which I wanted to use this the invert
>function:
>>>
>>> *My Elixir program is synchronizing Robot Framework source code
>files 
>>> with TestRail.  Robot Framework defines automated test cases. 
>TestRail is 
>>> a web-based Test Case Management system.   The goal is to
>synchronize 
>>> TestRail to contain all the tests that are defined in the Robot
>Framework 
>>> files, and in the same directory structure.*
>>>
>>> *Originally the Elixir program was specified to only create test
>cases in 
>>> TestRail.  When you are creating a test case, the TestRail API 
>>> <http://docs.gurock.com/testrail-api2/reference-cases#add_case>
>requires 
>>> you to specify the ID of the directory (aka "section") where the
>case is 
>>> written.  For this I use an Elixir Map to map paths to section IDs. 
>When I 
>>> want to create a file in directory "/path/to/test.robot", then I
>Lookup the 
>>> section ID from my map & then call the "add_case" TestRail API
>function.*
>>>
>>> *That version of the program was a success.  My boss was impressed
>and 
>>> next asked for enhancements to the program.  The new functionality
>being 
>>> requested is to have existing TestRail Test Cases get updated with
>the 
>>> latest test steps defined in Robot Framework.  Part of that update
>is to 
>>> verify that the path to the test case is the same in the Robot
>Framework 
>>> source code and in the TestRail.  In this case we first call the
>TestRail 
>>> API to lookup a test case, at which point we know the section ID
>that it 
>>> belongs to.  But we need to translate that to a directory path and
>confirm 
>>> that this path is the same location as where the test file exists in
>the 
>>> Robot Framework source code.  *
>>>
>>> *For updating, it makes sense to also be able to use an Elixir Map
>to map 
>>> from the Section ID back to the Path -- the inverse of the original
>map.  *
>>>
>>> *It is true that I could iterate through the original map until I
>found 
>>> the section ID in the value section, and then return the map index. 
>But 
>>> that seems awfully inefficient when you consider that there are
>hundreds of 
>>> test files and thousands of tests.  So I decided an inverse map
>would 
>>> provide faster lookup, at the cost of more memory being used.  Also
>note 
>>> that in my scenario both the indexes and the values are unique; it
>is a 
>>> 1-to-1 mapping.*
>>>
>>>
>>> This is just one example scenario.  I imagine other examples exist,
>or 
>>> else the invert() function would never have been created in the Ruby
>
>>> community.
>>>
>>> -- 
>>> 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/b2c7e58a-ad99-4458-a45e-9f7d5f7fce15%40googlegroups.com
>
>>>
><https://groups.google.com/d/msgid/elixir-lang-core/b2c7e58a-ad99-4458-a45e-9f7d5f7fce15%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/msgid/elixir-lang-core/d064aea6-7c8a-418a-91d6-8a4c4968da7f%40googlegroups.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
Kind regards,
Dmitry Belyaev

-- 
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/54972947-5E99-47C6-AD4A-825C5A2771DC%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:8202] Proposal: Short Hand Property Names

[Dmitry Belyaev]

>> --
>>>>>> 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/CgIxXdMUkx7LSD4AzBE_KZDElKV8B_fu45NFSdbRbW_c-hF-DkRZPHFRvidoE9FMwhTcmCgvPuyUMJDjF399n20oAwl6xRETkx_MO87NHzs%3D%40protonmail.com
>>>>>>
><https://groups.google.com/d/msgid/elixir-lang-core/CgIxXdMUkx7LSD4AzBE_KZDElKV8B_fu45NFSdbRbW_c-hF-DkRZPHFRvidoE9FMwhTcmCgvPuyUMJDjF399n20oAwl6xRETkx_MO87NHzs%3D%40protonmail.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-co...@googlegroups.com.
>>>>> To view this discussion on the web visit
>>>>>
>https://groups.google.com/d/msgid/elixir-lang-core/CAJhrTGw29%3D68m93JT47A0wrLugTC6Xppj428XfETr3j0iaUApQ%40mail.gmail.com
>>>>>
><https://groups.google.com/d/msgid/elixir-lang-core/CAJhrTGw29%3D68m93JT47A0wrLugTC6Xppj428XfETr3j0iaUApQ%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/22d888f8-0d32-4749-a80e-8714ef3bb0ea%40googlegroups.com
>>>
><https://groups.google.com/d/msgid/elixir-lang-core/22d888f8-0d32-4749-a80e-8714ef3bb0ea%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/msgid/elixir-lang-core/CAJr6D4QF5W5Hfj%3D7MYxgMME9MLEqcscz8Aw3VLsgRDkhoK8SyA%40mail.gmail.com
>>
><https://groups.google.com/d/msgid/elixir-lang-core/CAJr6D4QF5W5Hfj%3D7MYxgMME9MLEqcscz8Aw3VLsgRDkhoK8SyA%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/CAJhrTGxnEk%3DXvLwqnVkMwd%3DJohg7txN8UfSASHSey6%2BWhRbp4g%40mail.gmail.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
Kind regards,
Dmitry Belyaev

-- 
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/D8868870-33FF-4ABF-B0B1-E19873F4CEA2%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:7833] Re: [Proposal] Add GenServer.query and GenServer.handle_query

[Dmitry Belyaev]

I am not in favour of the proposal but can see some merit in handlers not 
modifying the state. For that case we might still use handle_call but allow the 
handlers to return the result without the state part like {:reply, reply} 


On 31 January 2018 01:48:54 GMT+11:00, "José Valim"  
wrote:
>The goal of the GenServer is to be generic and the functionality you
>ask
>for is already possible, so I prefer to stick with the generic APIs we
>have
>so far.
>
>Furthermore, introducing a new word also has downsides. Newcomers
>already
>wonder about call vs cast vs info, adding a new word will make things
>more
>confusing, and we won't get anything new out of it. I personally can't
>think of any optimization that would be possible with such callback.
>
>
>
>
>*José Valimwww.plataformatec.com.br
>Founder and Director of R*
>
>On Tue, Jan 30, 2018 at 3:25 PM, Ben Wilson 
>wrote:
>
>> 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 state.
>>> I find myself writing a lot of `handle_call` callbacks like
>>>
>>> def handle_call(request, _from, state) do
>>>   ...
>>>   ...
>>>   {:reply, result, state}
>>> end
>>>
>>>
>>>
>>>
>>> with the `handle_query` this could be written as
>>>
>>> def handle_query(request, _from, state) do
>>>   ...
>>>   ...
>>>   {:reply, result}
>>> end
>>>
>>>
>>> This is easier to read and write.
>>>
>>> A common use case is when you need some computation that depends on
>the
>>> GenServer state. Another is when the GenServer has a side effect and
>the
>>> calls to the server does not changes the actual process state but an
>>> external component.
>>>
>>>
>>> Together with the callback a new GenServer.query function should be
>>> implemented which calls the callback on the server context.
>>>
>>> I'm not familiar with the internals of the compiler/GenServer but
>this
>>> could also bring optimization opportunities.
>>>
>> --
>> 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/249e8c65-c2a2-4cbc-9956-
>> 1868d68b022f%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/CAGnRm4Koo0LRU9J8Eiwy0T1-NZZx96mJved%2BAQ-LPQ1KwPH9YQ%40mail.gmail.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/B4359D03-F949-4EE9-9740-C832E560C6B9%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:7290] Add --trace flag to mix compile

[Dmitry Belyaev]

Some compilers display a little more when --verbose is used. 

On 16 July 2017 06:53:53 GMT+10:00, "José Valim" 
 wrote:
>That always helps, so +1. The only question is if we should introduce a
>new
>flag or rather rely on MIX_DEBUG=1.
>
>
>
>*José Valim*
>www.plataformatec.com.br
>Skype: jv.ptec
>Founder and Director of R
>
>On Sat, Jul 15, 2017 at 9:41 PM, Michał Muskała 
>wrote:
>
>> Hello everybody,
>>
>> Today when something wired happens with compilation (like files
>> recompiling when they shouldn't be), it's hard to even figure out
>what
>> exactly is being compiled. I propose adding a --trace flag that would
>print
>> a bit more information. At least it would be nice to get information
>about
>> what files are being compiled, but it could also be interesting to
>see
>> something more - for example why a file is being compiled making use
>of the
>> compile-time dependancy information. This could greatly simplify
>debugging
>> compilation issues.
>>
>> Michał.
>>
>> --
>> 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/9e6f5eaa-2e8d-4e02-8ed1-66480609206f%40Spark
>>
>
>> .
>> 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/CAGnRm4KBobDvRqrjLrzhbkqqxxJzU2NHJF%3D5PAf7A1X6D9Et_w%40mail.gmail.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/AF647C00-8B0B-47CE-940C-78393D0786B9%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:6894] Re: Sorting maps when inspecting

[Dmitry Belyaev]

If I dump a map to logs I don't care about its order, I only want it to be as 
fast as possible. Logging already introduces a serious performance hit, and 
sorting would make logging even more expensive performance wise. 

As was mentioned previously if a map is small it's already sorted. So it would 
be a waste of time although insignificant. But if it's huge it would spend both 
cpu and memory to vuild sorted structure, and later would spend more cpu on its 
garbage collection. I don't like the idea of losing production performance only 
for development convenience. 

On 16 February 2017 07:25:51 GMT+11:00, Bruce Tate  wrote:
>Good points,  but isn't inspecting a map generally a development time
>activity? Especially big maps?
>
>Sometimes, optimizing people is the right thing to do. When you're
>looking
>at big lists of ecto objects and working to pick out an ID, having
>things
>in order is a big deal.
>
>-bt
>
>On Wed, Feb 15, 2017 at 2:17 PM, Tallak Tveide 
>wrote:
>
>> I believe it would be useful to not sort if there are very many keys
>as
>> well. A huge map would presumably be inspected in a short while,
>skipping
>> keys after the first few. Inspecting a huge map could become
>cpu/memory
>> intensive, which I would find surprising... anyways +1 from me
>>
>> --
>> 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/8a1f314b-efdb-468d-8dae-
>> ba6492aa0f95%40googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
>-- 
>Bruce Tate
>President, RapidRed, LLC
>Phone: 512.772.4312
>Fax: 512 857-0415
>
>Author of Seven Languages in Seven Weeks, Deploying Rails Applications,
>From Java to Ruby, Rails: Up and Running, Beyond Java, 6 others.
>
>-- 
>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/CAMp4_igDYoGoJFcM6B55cfjttcvZKaJ%3Dag8ksQQN-LtNGD2Nag%40mail.gmail.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/2649817D-21D7-4C50-B477-7038486C9849%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:6396] Proposal: Introduce `use GenServer, strict: true`

[Dmitry Belyaev]

It won't help if a function name is misspelled. 

On 24 September 2016 06:38:03 GMT+10:00, "José Valim" 
 wrote:
>>
>>   2. The default implementation of handle_info/1 will exit on any
>incoming
>> message, in the same way handle_cast/2 and handle_call/3 already do.
>>
>
>I believe this is not a good default because your processes may receive
>regular messages from other processes and you don't want to crash
>because
>of them. This is much more unlikely to happen with cast and call
>though, so
>we can afford to raise in cast and calls.
>
>I am wondering if the best way to solve this problem would be to have a
>@before_compile callback that checks if you defined any of the
>callbacks
>with a different arity while, at the same time, did not define one with
>the
>proper arity.
>
>-- 
>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/CAGnRm4JqC6rzBUYJHd9ij%3DQRH9-mPNDG1qGk1hTMZ6r331iZKA%40mail.gmail.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/A32068A7-2B9E-492C-AFD7-B311A70B06EE%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:6312] Improvement: the syntax for importing functions from modules

[Dmitry Belyaev]

I personally find the reversed order of imports such as in python or typescript 
very unnatural. Consider tools that could suggest what is available to import. 
You first write the module for them to work, don't you? At least I do write 
'import {} from module' in typescript and only then choose what actually I 
import.  So to me the current Elixir way has far more sense. 

On 13 September 2016 14:30:36 GMT+10:00, Jaap Frolich  
wrote:
>Hi,
>
>Currently when we import a single or a few functions from a module this
>is 
>the syntax to do it:
>
>  import Record, only: [defrecord: 2, extract: 2]
>
>As this is something that is something quite common to do in a module,
>the 
>syntax can be more user-friendly in my opinion.
>
> 1. The notation for a function is captured in data, while normally we 
>   describe functions with the function/arity notation
>  2. By default it imports *everything*, as this is often not what you 
>   want, it might be better to make it more explicit
>3. Aesthetics, but that might be personal, I think it does not read as 
>   nice
>
>So how about having something like below syntax in the language:
>
>  import defrecord/2, extract/2 from Record
>
>  import * from Record
>
>This might be hard to implement, other candidates could be:
>  
>  import {defrecord/2, extract/2}, from: Record
>  
>  import {*}, from: Record
>
>As it might be easier to implement in the language using macros.
>
>(while we keep the existing import macro around.)
>
>Let me know what you think!
>
>Cheers,
>
>Jaap
>
>-- 
>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/4e514d59-05bd-41c6-a1d5-a634b34ff350%40googlegroups.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
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/EFD2DCD2-6055-4DC7-B981-BA47281404AB%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:6034] Proposal: add native language support for handling Decimal types

[Dmitry Belyaev]

I'm not sure that decimal type is a must. All the handling can be done on 
integers representing cents or 0.1 of a currency or whatever is the 
required precision, and format the value as appropriate when presenting. That 
way you don't have  all the complications with guards and arithmetic operators.

On 1 July 2016 7:38:00 AM AEST, elxir@gmail.com wrote:
>First of all thanks everyone the constructiveness and the great ideas.
>I'm new to Elixir, so please forgive me if I've some bad assumptions.
>
>   1. Supporting number format like 1.32f or 12.45d, etc would be great
>2. Regarding using the regular arithmetic operators like +, -, * and / 
>for decimal type, I fail to see why it would be slower for integers for
>
>example. At the end I'd assume only the generated byte code matters. So
>why 
>not generated the usual byte code when integers or floats are used and 
>   generate some advanced logic when the operands are of decimal type?
> 3. Guards, following Peter's suggestion and using some logic for byte 
>  code generation (as mentioned in point #2) again I think it would be 
>   possible to handle decimal types transparently.
>  4. I think simplifying a couple of things, like handling the decimal 
>types (which is a must for financial apps)/removing boiler plates,
>would 
>   have a positive effect on language adoption as well
>  - I know it's off-topic, but it might worth mention that such 
>simplifications could do wonders, Elixir is great language but why not
>make 
>  even better out of the box, like:
> - instead of specifying a method like this:
> @spec add(number, number) :: number 
> def add(x, y), do: ...
> 
> it would be far easier to write it a single line like this:
> defs add(number x, number y) :: number, do: ...
> - or embrace the familiar lambda syntax for defining in-line 
>functions, so that parameters could be referenced by their name,
>instead of 
> their position
> - etc
>  
>
>-- 
>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/bb8734c9-5d6f-40ad-8bbb-0267786f971e%40googlegroups.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
Best wishes, 
Dmitry Belyaev

-- 
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/D5A1728D-A38F-4D26-A586-46D4924A5463%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:5856] Re: Proposal for required fields in struct expansion

[Dmitry Belyaev]

On 27 May 2016 12:44:49 AM AEST, "José Valim" <jose.va...@plataformatec.com.br> 
wrote:

>> additional arguments to defstruct. Why not to take all the unexpected
>> additional arguments (for example in defexception) and pass them to
>> defstruct explicitly? And defstruct will decide what to do with them.
>>
>
>Keep in mind this go directly against some other feature proposed for
>defstruct which was for it to explicitly check the options passed to it
>and
>raise for any unknown option. If we simply accept anything in
>defstruct, if
>you make a typo when giving an option, it will go undetected (as a
>module
>attribute would).
>
I didn't say defstruct would silently ignore the unknown arguments. It should 
reject such definition. 

>As attributes are not parameters how to decide where they might be
>> documented?
>>
>
>You can't document an attribute, so it needs to be documented in every
>construct that uses it, in this case, defstruct, defexception and so
>on. So
>it is not really different from options in this aspect.

Exactly. If the behaviour depends on the point of application and is documented 
there along with normal arguments, it's not any different than an argument. Why 
not to make it an argument then? 
-- 
Best wishes, 
Dmitry Belyaev

-- 
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/01FDD6C7-B605-4C35-B6F2-3678293ADF90%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:5854] Proposal for required fields in struct expansion

[Dmitry Belyaev]

If you want composability how about:

require_keys [:a, :b],
in: defstruct [:a, :b, :c]

require_keys [:message],
in: defexception ... 

Also repeating mandatory keys with some default values seems quite annoying. 

On 26 May 2016 3:06:25 AM AEST, "José Valim" <jose.va...@plataformatec.com.br> 
wrote:
>>
>> All other things being equal or very similar, I think the interface
>which
>> prevents sloppiness is better.
>>
>
>Except they are not equal and similar. One provides composability
>exactly
>because it is less restrictive. The other provides better feedback for
>being more restrictive with checking of options and less composable. We
>can
>make both assessments without bringing the sloppy programmer into the
>discussion.
>
>
>> It will break on compile, hinting me that I didn’t move the complete
>code.
>> Yes, I need to pay attention, but compiler has my back.
>>
>
>Not necessarily?
>
>if some_option? do
>  # ...
>  defstruct foo: nil
>else
>  defstruct foo: nil, bar: :baz
>end
>
>
>> The latter approach means I have to know the semantics of @derive,
>> @require and defstruct/defexception/schema, to know that these things
>tie
>> together.
>>
>
>In both cases you need to understand the semantics of derive and
>require.
>For module attributes though, you do need to know how these things tie
>in
>together. It is the trade-off between restrictive and composable.
>
>-- 
>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/CAGnRm4%2BicfA9Z%3DesQ%3Dw08XmtD_LvQKF2f4%3DEYx_N96fhL8FB5g%40mail.gmail.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
Best wishes, 
Dmitry Belyaev

-- 
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/196BA74C-E4AC-4410-AFFA-C6F6D2BA00A2%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:5701] Home Directory On Windows

[Dmitry Belyaev]

s message because you are subscribed to a topic in
>the
>> Google Groups "elixir-lang-core" group.
>> To unsubscribe from this topic, visit
>>
>https://groups.google.com/d/topic/elixir-lang-core/g22tkekQcMo/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
>>
>https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JQiA0PnfZoJT6ZF5ZgmOVUZ%3Djkp1_0Qrs93%2B_MRwuqag%40mail.gmail.com
>>
><https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JQiA0PnfZoJT6ZF5ZgmOVUZ%3Djkp1_0Qrs93%2B_MRwuqag%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
>-- 
>Onorio Catenacci
>
>http://onor.io
>http://www.google.com/+OnorioCatenacci
>
>-- 
>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/CAP%3DvNq9LjX9HhP4Ef0TSC-rMXG-m4J%3DybYKAhBm%3DJwoMd%2BioJw%40mail.gmail.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
Best wishes, 
Dmitry Belyaev

-- 
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/59793331-55D2-4236-B8B4-5F65F447E0D1%40gmail.com.
For more options, visit https://groups.google.com/d/optout.