Re: [elixir-core:6308] modules that are required automatically

[eksperimental]

Thank you José for your answer,
so why is so I don't need to require IO and Enum?

$ elixir -e "IO.inspect(Enum.at(1..5, 2))"
3


On Tue, 13 Sep 2016 08:39:24 +0200
José Valim  wrote:

> You always need to require a module before using it. The only exception is
> the Kernel module.
> 
> 
> 
> *José Valim*
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Director of R&D
> 
> On Tue, Sep 13, 2016 at 6:40 AM, eksperimental 
> wrote:
> 
> > I'm hacking Elixir core, and I haven't managed to find the code that makes
> > some modules not to be
> > required in order to use them. Same as it happens with Enum for example.
> >
> > Can anybody guide me in what's the procedure to achive this? since I'm
> > trying to avoid "require
> > NewModule" from a macro I'm working on.
> >
> > Thank you
> >
> > --
> > 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/20160913114058.0f10b282.
> > eksperimental%40autistici.org.
> > 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/20160913195458.31cf0f06.eksperimental%40autistici.org.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:6309] modules that are required automatically

[Louis Pilfold]

Functions do not need to be required, only macros :)

Cheers,
Louis

On 13 September 2016 at 13:54, eksperimental
 wrote:
> Thank you José for your answer,
> so why is so I don't need to require IO and Enum?
>
> $ elixir -e "IO.inspect(Enum.at(1..5, 2))"
> 3
>
>
> On Tue, 13 Sep 2016 08:39:24 +0200
> José Valim  wrote:
>
>> You always need to require a module before using it. The only exception is
>> the Kernel module.
>>
>>
>>
>> *José Valim*
>> www.plataformatec.com.br
>> Skype: jv.ptec
>> Founder and Director of R&D
>>
>> On Tue, Sep 13, 2016 at 6:40 AM, eksperimental 
>> wrote:
>>
>> > I'm hacking Elixir core, and I haven't managed to find the code that makes
>> > some modules not to be
>> > required in order to use them. Same as it happens with Enum for example.
>> >
>> > Can anybody guide me in what's the procedure to achive this? since I'm
>> > trying to avoid "require
>> > NewModule" from a macro I'm working on.
>> >
>> > Thank you
>> >
>> > --
>> > 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/20160913114058.0f10b282.
>> > eksperimental%40autistici.org.
>> > 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/20160913195458.31cf0f06.eksperimental%40autistici.org.
> 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/CAM-pwt6Qh340ATYosvrNt%3DWNLCz36dyWYHer9m5dpkbxYS_gpg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Onorio Catenacci]

Hi Jaap,

Is your basic concern the 

[function: arity]

notation as opposed to the 

function/arity 

notation used in other places?  I mean are you basically asking for the 
notation to be unified?  If so, would [function/arity, function/arity] 
suffice assuming it were supportable?  Something like 

import Record, only: [defrecord/2, extract/2]

Just trying to understand the basis of your proposal.

oc


On Tuesday, September 13, 2016 at 12:30:37 AM UTC-4, 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/d094c92b-f703-4ea7-974b-7ddd49be5b79%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:6311] modules that are required automatically

[Allen Madsen]

Both `import` and `use` will do the require for you.

See: http://elixir-lang.org/getting-started/alias-require-and-import.html

Until I read this, I also didn't understand why I didn't need to use
require everywhere.
Allen Madsen
http://www.allenmadsen.com


On Tue, Sep 13, 2016 at 9:02 AM, Louis Pilfold  wrote:
> Functions do not need to be required, only macros :)
>
> Cheers,
> Louis
>
> On 13 September 2016 at 13:54, eksperimental
>  wrote:
>> Thank you José for your answer,
>> so why is so I don't need to require IO and Enum?
>>
>> $ elixir -e "IO.inspect(Enum.at(1..5, 2))"
>> 3
>>
>>
>> On Tue, 13 Sep 2016 08:39:24 +0200
>> José Valim  wrote:
>>
>>> You always need to require a module before using it. The only exception is
>>> the Kernel module.
>>>
>>>
>>>
>>> *José Valim*
>>> www.plataformatec.com.br
>>> Skype: jv.ptec
>>> Founder and Director of R&D
>>>
>>> On Tue, Sep 13, 2016 at 6:40 AM, eksperimental 
>>> wrote:
>>>
>>> > I'm hacking Elixir core, and I haven't managed to find the code that makes
>>> > some modules not to be
>>> > required in order to use them. Same as it happens with Enum for example.
>>> >
>>> > Can anybody guide me in what's the procedure to achive this? since I'm
>>> > trying to avoid "require
>>> > NewModule" from a macro I'm working on.
>>> >
>>> > Thank you
>>> >
>>> > --
>>> > 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/20160913114058.0f10b282.
>>> > eksperimental%40autistici.org.
>>> > 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/20160913195458.31cf0f06.eksperimental%40autistici.org.
>> 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/CAM-pwt6Qh340ATYosvrNt%3DWNLCz36dyWYHer9m5dpkbxYS_gpg%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/CAK-y3CubH98NVNkhtfYsVZN9qtZndFR1CwL%2BDiP1XCrDpxeS4g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Norbert Melzer]

I do not like the new python-like syntax for import, but to be honest, I do
like to specify functions in `name/arity` instead of `{name, arity}`.

Perhaps we can either build upon the division operator in the AST or we use
the capture syntax as in `import Enum, &map/2`. This should be just an
addition to the "old" tuple notation and is getting converted into it.



José Valim  schrieb am Di., 13. Sep. 2016
um 08:54 Uhr:

> Thank you Jaap!
>
> The benefit of today's syntax is that the arguments are data, which makes
> them easy to control and manipulate. Imagine you want to dynamically import
> some data, how do you dynamically build a list or a tuple of {defrecord/2,
> extract/2} entries?
>
> The data syntax is also what you get back from all of the introspection
> functions in Elixir, such as String.__info__(:functions). Also, today's
> syntax support `:except` and other options, which are not considered in the
> new syntax.
>
> I would like to see those points considered before further considering a
> new syntax.
>
>
>
> *José Valim*
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Director of R&D
>
> On Tue, Sep 13, 2016 at 6:30 AM, 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.
>>
>
> --
> 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/CAGnRm4KLGhV34Xu_Ry8g1_VZPKtrju%3DQPiiZ5y7Ss8U8nAtpUw%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/CA%2BbCVsu2tZmw3FQPd3rtJES9a1ueCdddtkJ_bS7O1FOCcJF4Zw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:6312] Elixir way to handle errors in pipes

[Jaap Frolich]

Another alternative is to have a function that forwards everything that is 
not :ok, and does something with {:ok, value} responses:

  defp if_ok(input, fun) when is_function(fun) do
input
|> case do
  {:ok, content} ->
case fun.(content) do
  # if function does not return a tuple, but a map, make it {:ok, 
res}
  res = %{} -> {:ok, res}
  other -> other
end
  other -> other
end
  end
  defp if_ok(input, value) do
if_ok input, fn (_) -> value end
  end

Then you could chain in the following way

do_something
|> if_ok(&Repo.delete/1)
|> if_ok(&AlgoliaService.delete_content_item/1)
|> if_ok(&broadcast_content_item_removed/1)
|> if_ok(:ok)

Can read a bit nicer than with, and easier to implement in existing 
pipeline. Still quite clean imo.

Cheers,

Jaap

On Monday, August 15, 2016 at 7:29:59 PM UTC+8, alco wrote:
>
> The Elixir way is to use the pipe and `with` where each is more suitable 
> for the task. So if you need to write a sequence of function calls where 
> some or all are expected to return an error, `with` would be the most 
> appropriate tool to use.
>
> One key difference between a pipeline and `with` is that the latter stops 
> evaluation as soon as it encounters the first failed match. Whereas with a 
> pipeline you'd have to wrap all constituent functions to pass the error 
> from a previous step down to the next one. I see it as a downside to trying 
> to use the pipe in places where it is more important to explicitly handle 
> errors.
>
> On Mon, Aug 15, 2016 at 2:12 PM, Alvise Susmel  > wrote:
>
>> Hi, 
>>
>> I've started thinking about this, as maybe many of you, when I needed to 
>> stop the pipe when an error is returned. I've seen that there are different 
>> conversation about this, but I haven't clear what is the *elixir way* to 
>> handle errors using pipes. 
>>
>> I see two ways for achieving the same result.* The first* is to use the 
>> *pipe* *|>* and for each function catch the error and propagate it down. 
>> The error has to be always returned with the same pattern, like {:error, 
>> reason} 
>>
>> connect
>> |> receive_image
>> |> resize
>> |> rotate
>> |> save
>>
>>
>> If *receive_image* returns an error,  *resize* needs to handle it
>>
>> def resize({:error, _}=error), do:error
>>
>> and to propagate it down through the pipe. So *rotate* needs to do the 
>> same, etc..
>>
>> *The* *second* way I see is using the *with*, which to me seems to be 
>> more generic (and less clean)
>>
>> with {:ok, pid} <- connect,
>>{:ok, image} <- receive_image(pid),
>>{:ok, resized_image} <- resize(image),
>>   {:ok, rotated_image} <- rotate(resized_image),
>>   :ok <- save(rotated_image)
>> do: IO.puts "saved"
>>
>>
>> Now, the cool thing about *with* is that when one of the assignments 
>> fails, it exits returning the value that failed the pattern match. 
>>
>> So, to you, what is the elixir way on handling the return errors on pipes 
>> ? Could *"with" *be seen as a new (and more generic) way of piping with 
>> error handling ?
>>
>> Thanks
>>
>> Alvise
>>
>> -- 
>> 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/1dc86df2-eca0-4fa5-b883-7b9c2df36444%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/4f0835a1-790a-4b1e-9dad-ed593292bc37%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:6312] Re: why are zero arity anonymous functions not allowed?

[Scott Parish]

Thanks for the details! Makes a lot more sense now.

On Wed, Sep 7, 2016 at 11:58 AM,  wrote:

> According to https://groups.google.com/forum/#!topic/elixir-lang-
> core/GeXNvzzmdps, it seems that if you allow zero arity with & there is
> an ambiguity when parsing the expressions.
> &fun/2 could be parsed as (fn -> fun end) / 2 or fn(x,y) -> fun(x,y) end
>
>
> On Thursday, July 21, 2016 at 12:29:06 AM UTC-3, Scott Parish wrote:
>>
>> Another one is: :timer.tc(&mycode(args))
>>
>> Or the case where this originally came up today: retry_num_times(10,
>> &fn_that_may_not_succeed_immediately!(args))
>>
>> On Wed, Jul 20, 2016 at 7:22 PM, Ben Wilson  wrote:
>>
>>> 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(&foo(args))` is more
>>> succinct than `Task.async(fn -> foo(args) end)`. Spawning processes and the
>>> like are about the only cases I can think of where zero arity functions are
>>> used frequently, but it does seem like it would be a win for consistency
>>> and readability in certain cases.
>>>
>>> Perhaps there are ambiguities introduced however without &1 and friends?
>>> I'm sure one of the core team members will clarify.
>>>
>>> On Wednesday, July 20, 2016 at 8:01:01 PM UTC-4, Scott Parish wrote:

 It seems inconsistent that the anonymous function sugar is not allowed
 for zero arity functions. Is there a good reason for this, or did this need
 to be proposed as a feature request instead of a bug?

 Reference: https://github.com/elixir-lang/elixir/issues/5042

 Thanks

 --
>>> You received this 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/to
>>> pic/elixir-lang-core/HsrPwDjg964/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> elixir-lang-co...@googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/elixir-lang-core/41bfc1d9-fce2-46f1-b72b-5429d0f4fc6b%
>>> 40googlegroups.com
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this 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/HsrPwDjg964/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/254f4040-f343-48a0-964e-
> a8fef7892893%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/CABvdOJsfT_6-NONQU8rWLwphezuT_fBOkN5B2K3F-ZETdTGRHA%40mail.gmail.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:6312] Suggestion: Map.deep_merge

[Bruce Tate]

It seems like you could have a Map.deep_merge/2 which has an explicit
behavior for conflicting keys (e.g. first wins or second wins), and a
Map.deep_merge/3 which also accepts a function to merge individual keys.

-bt

On Sat, Sep 10, 2016 at 1:47 AM, Tobias Pfeiffer  wrote:

> On 09/09/2016 06:00 PM, OvermindDL1 wrote:
> > On Friday, September 9, 2016 at 9:25:05 AM UTC-6, OvermindDL1 wrote:
> > >
> > I looked through my big project to see a couple of areas where I
> > deep-merge, in all cases I needed a resolver function (usually appending
> > lists together or sorting something that was not a map or so forth).
> >  Thus if a deep_merge is made, even in a library, it needs a version
> > that can take a resolver function for non-map values.
>
> I think this is a good idea. For instance Renan's version (which I like)
> concatenates lists which is a behaviour I'd really not want in my
> current project. Question is also about keywords then though.
>
> API might get to be more complex then. Maybe just Map.deep_merge and a
> custom resolver function for every other value?
>
> Tobi
>
> > --
> > 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/
> 96b6870e-e868-40eb-9013-4cdfb669f391%40googlegroups.com
> >  96b6870e-e868-40eb-9013-4cdfb669f391%40googlegroups.
> com?utm_medium=email&utm_source=footer>.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> http://www.pragtob.info/
>
> --
> 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/7458c350-bf3b-f88b-3214-7e928ea3c5c5%40gmail.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_igE40wDiRiPXtJGdVBCYEXXxVa%2Bs-%3D6hLv17fBZ%3D_%3DOug%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.