Re: [elixir-core:9516] [Proposal] Support transforming lists to type specs

2020-05-19 Thread Kip
If its a construct and not a function does that imply changes to the lexer 
and parser? If so, then perhaps $one_of or something else that is not a 
valid identifier in Elixir.

On Saturday, May 16, 2020 at 5:25:50 PM UTC+8, José Valim wrote:
>
> Correct. My concern is someone having "@type one_of(X)" as an existing 
> type.
>
> On Sat, May 16, 2020 at 11:04 AM Wiebe-Marten Wijnja  > wrote:
>
>> I like the name `one_of` exactly because it is similar to what is in use 
>> by e.g. `StreamData` right now.
>>
>> If the construct is specific to Kernel.Typespec, then this would also 
>> limit conflicts with existing code, right?
>> On 16-05-2020 10:40, José Valim wrote:
>>
>> We wouldn't make it a macro per so, but a construct specific to 
>> Kernel.Typespec. It should be straight-forward. My biggest concern at this 
>> point is the name. :)
>>
>>
>> On Sat, May 16, 2020 at 10:21 AM Kip > 
>> wrote:
>>
>>> I had the `one_of` approach as my other alternative but figured adding 
>>> another function to Kernel (or elsewhere) may not be in favour. What do you 
>>> suggest I do next to progress this `one_of` idea as a poc? 
>>>
>>> Thanks too for the reduction, my attempts were making that far too 
>>> complicated!
>>>
>>> On Saturday, May 16, 2020 at 3:29:27 PM UTC+8, José Valim wrote: 

 Today you can do it like this:

 var = Enum.reduce(@list, &{:|, _. [&1, &2]}
 @type foo :: unquote(var)

 But it may be worth introducing something like you describe but it 
 probably makes sense to do it via a construct, such as @type foo :: 
 one_of(@var) that does the conversion for you. I think automatically 
 converting the list can be confusing, because people may think that [:foo, 
 :bar] implies a specific ordering, for example.

 I am just not sure of a good name. one_of may conflict with existing 
 code.

 On Sat, May 16, 2020 at 6:25 AM Kip  wrote:

> It's not uncommon to have domain overlap between lists of valid tokens 
> (used for validations) and type specs. For example: 
>
>   @standard_formats [
> :standard,
> :accounting,
> :currency,
> :percent
>   ]
>
>   @currency_formats [
> :currency,
> :accounting,
> :currency_long,
> :currency_short
>   ]
>
>   @currency_symbol [
> :standard,
> :iso
>   ]
>
>   @type standard_formats :: :standard | :currency | :accounting | 
> :short | :long
>   @type currency_formats ::  :currency_short | :currency_long | 
> :decimal_short | :decimal_long
>   @type currency_symbol :: :standard | :iso
>
> It would go good to remove one source of error by being able to allow 
> compile time use of a list as the subject of  @typespec. For example:
>
> @type currency_symbol :: @currency_symbol # Any compile-time 
> resolvable list
>
> Of course a macro can be introduced to do this but its quite difficult 
> to achieve since it requires manual manipulation of AST.
>
> Proposal worth considering? Or consign to the history of my 
> less-than-helpful ideas :-)
>
>
> -- 
> 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-l...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/elixir-lang-core/36f821aa-d718-48aa-a9e8-2f6d5e440632%40googlegroups.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-l...@googlegroups.com .
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/elixir-lang-core/3577d145-b325-4c67-806c-d634df15ad5a%40googlegroups.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-l...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2Bqvg4suaUa6CTDUavrjcZq-U3-2k08m7MMhKBEo7Fakw%40mail.gmail.com
>>  
>> 
>> .
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> 

Re: [elixir-core:9513] Proposal: Add Agent.get/1, where Agent.get(agent) is equivalent to Agent.get(agent, fn x -> x end)

2020-05-19 Thread José Valim
Getting the whole agent state is often a bad idea, so we want to force you
to think if you really need the whole state or part of it. Depending on the
data, you can have a drastic difference between:

Agent.get(pid).some_field

and:

Agent.get(pid, & &1.some_field)

So in the cases you do want it all, being explicit about it doesn't hurt.

On Tue, May 19, 2020 at 3:10 PM Pierre Le Gall 
wrote:

> Hello,
>
> Writing `Agent.get(agent, fn x -> x end)` or even shorter
> `Agent.get(agent, &(&1))` is kind of verbose for this non-specific
> behavior.
>
> Maybe the `fun` argument of `Agent.get/2` could be set to `fn x -> x
> end` by default making `Agent.get/1` available?
>
> --
> Pierre
>
> --
> 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/CAL3hriJqr95fxzLaDXadYsUNWR1-Njzcgtpr-NJp8kS%3Ddin0Jw%40mail.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/CAGnRm4KXHaye%2BdsAq4x%3DwDx7L9mTK9P4%2Bv0PZZ4vDLjV0Pc-qg%40mail.gmail.com.


[elixir-core:9512] Proposal: Add Agent.get/1, where Agent.get(agent) is equivalent to Agent.get(agent, fn x -> x end)

2020-05-19 Thread Pierre Le Gall
Hello,

Writing `Agent.get(agent, fn x -> x end)` or even shorter
`Agent.get(agent, &(&1))` is kind of verbose for this non-specific
behavior.

Maybe the `fun` argument of `Agent.get/2` could be set to `fn x -> x
end` by default making `Agent.get/1` available?

--
Pierre

-- 
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/CAL3hriJqr95fxzLaDXadYsUNWR1-Njzcgtpr-NJp8kS%3Ddin0Jw%40mail.gmail.com.