Re: [elixir-core:10605] Re: Introduce :let in for-comprehensions

[Louis Pilfold]

Heya

> Put yourself into the shoes of someone starting with Elixir and having to
solve this problem. How many concepts do you have to learn to get this
(allegedly simple) task done?

This is the point of view from which I wrote my email- I think this
proposal increases the amount of knowledge a newcomer would need to have in
order to understand this code.

They would both be unable to use their pre-existing understanding of
mutable variables (as the rules are very different), and there would be
another set of rules to learn that do not exist elsewhere in Elixir. My
hunch is that this feature is one for power-users, not one for newcomers.

> How many concepts do you have to learn to get this (allegedly simple)
task done?

Adding a new concept to learn only reduces the number of concepts needed to
learn in order to perform a new task if it can replace several of the
others. This concept can only be applied within `for`, and then only in a
very restricted fashion, so I don't think it would enable new Elixir
developers to skip over learning Elixir as it is today. Because of this I
believe it's now N+1 concepts to learn.

Cheers,
Louis

On Thu, 16 Dec 2021 at 18:10, José Valim  wrote:

> Hi everyone,
>
> Thanks for the input so far. I have one favor to ask: could everyone
> please think carefully about the problem statement?
>
> Put yourself into the shoes of someone starting with Elixir and having to
> solve this problem. How many concepts do you have to learn to get this
> (allegedly simple) task done? I am aware most people in this mailing list
> are comfortable with the Enum.map_reduce/3 solution presented, but we need
> to be careful to not fall into the trap of "I've climbed this mountain, I
> bet others can too!". In the linked repository, there are solutions in many
> languages, and Elixir (and most functional programming languages) are worse
> than most of the mainstream languages in terms of size, noise, and required
> concepts.
>
> I am NOT saying we need to sacrifice the things that make Elixir be
> Elixir. I am NOT proposing to "dumb down" the language. There are valid
> points against this proposal! But I think there would be a strong
> dissonance if we can't agree on the problem statement and on how noisy and
> mechanical the current functional solution looks. :)
>
> Some comments/replies below (I am using bold for questions/previous
> remarks).
>
> ---
>
> *> To what extent can one use these mutable values with other language
> features?*
>
> It would only be at the comprehension root. You are correct there would
> still cause confusion as people may expect it to apply in other places.
>
> *> Overall I don't feel this added complexity and potential for confusion
> is worth the benefits here. This brings no more expressive power to the
> language.*
>
> The goal was precisely to not add more expressive power (specifically, not
> add mutation). :D
>
> This is a bit unrelated and I can't remember exactly where I read/heard it
> but there is a quote along the lines: "Expressive power is a good measure
> for language capabilities but it is not a good measure for language
> features". Otherwise, we would all be writing fun(arg1)(arg2) instead of
> fun(arg1, arg2). :)
>
> *>  It’d be great to have somewhat like `take: 1` option to stop
> evaluation immediately after it has been emitted into `do:` clause.*
>
> There is already an open issue for the :take option.
>
> *> 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`*
>
> Correct. This is personally my biggest concern against this proposal,
> especially because we have removed features in the past (imperative
> assignments for conditionals) because they broke this property.
>
>
> On Thu, Dec 16, 2021 at 5:54 PM Ben Wilson  wrote:
>
>> 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 multi-line-thing using the lesson and counter
>>   end
>> ```
>>
>> I can refactor this into:
>>
>> ```
>>   for lesson <- section["lessons"], reduce: 0 do
>> counter ->
>>   complex_operation(lesson, counter)
>>   end
>>
>>   def complex_thing(lesson, counter) do
>> # complex multi-line-thing using the lesson and counter
>>   end
>> ```
>>
>> And everything just works, as is normal in Elixir code. The proposed
>> changes would (as far as I can see) break this and that feels very
>> unexpected and foreign.
>>
>> I sympathize with the problem space, but so far it's a -1 for me on this
>> particular proposed improvement.
>>
>> - Ben
>> On Thursday, December 16, 2021 at 10:02:49 AM UTC-5 José Valim wrote:
>>
>>> Note: This proposal contains images and rich text that may not display
>>> correctly in your email. 

Re: [elixir-core:10597] Introduce :let in for-comprehensions

[Louis Pilfold]

Heya

My initial impression is that this is quite a large departure from the
semantics of all other constructs in the language, and the usual rules for
reading Elixir no longer apply. The "return value" of a loop block is no
longer the final line of the block, it could be spread throughout it.

To what extent can one use these mutable values with other language
features?

Is this permitted?

for lesson <- lessons, let: lesson_counter do
  if lesson.active? dolesson_counter = lesson_counter + 1
  endend

Or this?

for lesson <- lessons, let: lesson_counter do
  Enum.each(lesson.sessions, fn(_) ->lesson_counter = lesson_counter + 1
  end)end

If the above snippet with an anonymous function does not work, I think that
may be quite surprising to newcomers as both `Enum.*` and `for` would work
in languages which have conventional mutable variables (which they will
likely be mentally using as a reference).

Overall I don't feel this added complexity and potential for confusion is
worth the benefits here. This brings no more expressive power to the
language, and personally I don't have any issues with the "before" examples
here using existing language features.
Having said that, I'm not a big user of `for`, so the opinions of others
may be more useful here!

Cheers,
Louis


On Thu, 16 Dec 2021 at 15:02, José Valim  wrote:

> Note: This proposal contains images and rich text that may not display
> correctly in your email. If so, you can read this proposal in a gist
> .
>
> There is prior art in languages like Common Lisp, Haskell, and even in C#
> with LINQ on having very powerful comprehensions as part of the language.
> While Elixir comprehensions are already very expressive, allowing you to
> map, filter, reduce, and collect over multiple enumerables at the same
> time, it is still not capable of expressing other constructs, such as
> map_reduce.
>
> The challenge here is how to continue adding more expressive power to
> comprehensions without making the API feel massive. That's why, 7 years
> after v1.0, only two new options have been added to comprehensions, :uniq
> and :reduce, to a total of 3 (:into, :uniq, and :reduce).
> Imperative loops
>
> I have been on the record a couple times saying that, while many problems
> are more cleanly solved with recursion, there is a category of problems
> that are much more elegant with imperative loops. One of those problems
> have been described in the "nested-data-structures-traversal"
> 
> repository, with solutions available in many different languages. Please
> read the problem statement in said repository, as I will assume from now on
> that you are familiar with it.
>
> Personally speaking, the most concise and clear solution is the Python
> one, which I reproduce here:
>
> section_counter = 1lesson_counter = 1
> for section in sections:
> if section["reset_lesson_position"]:
> lesson_counter = 1
>
> section["position"] = section_counter
> section_counter += 1
>
> for lesson in section["lessons"]:
> lesson["position"] = lesson_counter
> lesson_counter += 1
>
> There are many things that make this solution clear:
>
>- Reassignment
>- Mutability
>- Sensitive whitespace
>
> Let's compare it with the Elixir solution I wrote and personally prefer
> .
> I am pasting an image below which highlights certain aspects:
>
> [image: Screenshot 2021-12-13 at 10 02 48]
> 
>
>-
>
>Lack of reassignment: in Elixir, we can't reassign variables, we can
>only rebind them. The difference is, when you do var = some_value
>inside a if, for, etc, the value won't "leak" to the outer scope. This
>implies two things in the snippet above:
>1. We need to use Enum.map_reduce/3 and pass the state in and out
>   (highlighted in red)
>   2. When resetting the lesson counter, we need both sides of the
>   conditional (hihhlighted in yellow)
>-
>
>Lack of mutability: even though we set the lesson counter inside the
>inner map_reduce, we still need to update the lesson inside the
>session (highlighted in green)
>-
>
>Lack of sensitive whitespace: we have two additional lines with end in
>them (highlighted in blue)
>
> As you can see, do-end blocks add very litte noise to the final solution
> compared to sensitive whitespace. In fact, the only reason I brought it up
> is so we can confidently discard it from the discussion from now on. And
> also because there is zero chance of the language suddenly becoming
> whitespace sensitive.
>
> There is also zero chance of us introducing reassignment and making
> mutability first class in Elixir too. The reason for 

Re: [elixir-core:10078] [Proposal] Syntax for overriding map/struct typespec field

[Louis Pilfold]

Hello!

Correct me if I'm wrong but I believe this isn't something that Erlang
typespecs support, or at least there is no syntax for it.

What do you see this compiling to? Elixir has to work with the capability
of Erlang here.

Cheers,
Louis

On Fri, 5 Feb 2021, 22:39 Bernardo Amorim,  wrote:

> Hi folks, I'm not even sure if this is possible nor if it was raised
> before nor if there is already another way of doing something similar. But
> this is something that I've been thinking a lot recently and I'd like to
> know if it is possible and desirable. If it is, I can help with a PR later
> on.
>
> The "problem":
>
> It is usual to when we have a Struct (specially Ecto.Schemas) to define a
> `@type t()` with the fields. Let's say we have a Struct with a few fields
> like this:
>
> ```
> defmodule MyStruct do
>   defstruct [:a, :b, :c]
>   @type t() :: %__MODULE__{
> a: integer() | nil,
> b: integer() | nil,
> c: integer() | nil
>   }
> ```
>
> Now imagine I want to define a function that receives a struct but
> requires one of these fields to be non null. What we have to do right now
> is to:
>
> ```
> @type my_struct_with_a() :: %MyStruct{
>   a: integer(),
>   b: integer() | nil,
>   c: integer() | nil
> }
> ```
>
> (Ok, maybe in some cases we do not need to redefine all the other fields
> since they might be irrelevant, but let's assume we actually want to type
> everything)
>
> The proposal:
>
> For map values when we just want to change one field we can do something
> like: ```%MyStruct{my_struct | a: 1}```, but for types this is not possible.
>
> My proposal would be to have something like this:
>
> ```
> @type my_struct_with_a() :: %MyStruct{MyStruct.t() | a: integer()}
> ```
>
> That would generate a type with all fields copied from `MyStruct.t()` but
> with `:a` changed to `integer()` instead of `integer() | nil`.
>
> The caveats I see is what to do when the type is not just a map type
> (maybe it is a sum type, maybe it is not even a map, etc).
>
> What do you folks think about this?
>
> Thanks,
> Bernardo Amorim
>
> --
> 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/b152b04f-3c6b-4052-92aa-d23724ed0f92n%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-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/CABu8xFCeqgNAOp1o%3D0JJ%2B9JYwF20H9-%2BnD2DLoY%3DuSisyGB8NA%40mail.gmail.com.

Re: [elixir-core:9906] [Proposal] Inspection using a function

[Louis Pilfold]

Heya

"apply" is the name I first thought of here. In fact I've tried to use
apply like this before!

Cheers,
Louis

On Tue, 29 Dec 2020, 20:22 Austin Ziegler,  wrote:

> Couldn’t this be a special case of `Kernel.apply/2`?
>
> ```elixir
> @spec apply(fun | any, list(any) | fun) :: any
> def apply(arg, fun) when is_function(fun, 1)) do
>   fun.(arg)
> end
>
> def apply(fun, args) do
>   :erlang.apply(fun, args)
> end
> ```
>
> This would read really well (IMO):
>
> ```elixir
> [1, 2, 3, 5, 7]
> |> apply((&1, fn x -> x * 2 end))
> ```
>
> If it’s preferred not to make a special form of apply/2, then perhaps
> `then_apply/2`?
>
> -a
>
> On Tue, Dec 29, 2020 at 1:11 PM Paul Clegg 
> wrote:
>
>> On Tue, Dec 29, 2020 at 1:47 AM José Valim  wrote:
>>
>>> I propose we simply add two functions to Kernel: tap and then.
>>>
>>> 1. tap receives an anonymous function, invokes it, and returns the
>>> argument. It can be found in Ruby and .NET Rx.
>>>
>>> 2. then receives an anonymous function, invokes it, and returns the
>>> result of the anonymous function. It will be how we can pipe to anonymous
>>> functions in Elixir. It is named andThen in Scala and known as then in many
>>> promise libraries across ecosystems.
>>>
>>
>> I'm all for "tap"; I've been writing this function myself for a while
>> now, as easy as it is...  Not as sure about "then", though, I've been able
>> to get this to work without much problem, ala;
>>
>> iex(30)> foo = &(IO.puts(&1))
>> /1
>> iex(31)> "biff" |> (foo).()
>> biff
>> :ok
>> iex(32)> foo = &(&1 <> &2)
>> #Function<43.97283095/2 in :erl_eval.expr/5>
>> iex(33)> "biff" |> (foo).("bar")
>> "biffbar"
>>
>> The parens + .() combination seem to work just fine without any
>> additional work.  It's just the tap that gets messy if you want to do it
>> "inline" often:
>>
>> iex(34)> "biff" |> (fn x -> IO.puts("foo"); x; end).()
>> foo
>> "biff"
>>
>> ...so for that, I'd love 'tap()' so I don't forget to return the original
>> x.  :D
>>
>> ...Paul
>>
>>
>>
>>
>>
>>
>> --
>> 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/CAD3kWz-MCWvdbmTRe0qP5gz57%3Diy5fOcsmNLNT1cZRe5N_D9MA%40mail.gmail.com
>> 
>> .
>>
>
>
> --
> Austin Ziegler • halosta...@gmail.com • aus...@halostatue.ca
> http://www.halostatue.ca/ • http://twitter.com/halostatue
>
> --
> 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/CAJ4ekQtrodwKZsN0KE_omixojeuge1N2-3DDZjMbwvtNR_naSA%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/CABu8xFA%2BUen_jgrt96skqmv91JCdV3-1JiRNz1fyL_w6B0SuWQ%40mail.gmail.com.

Re: [elixir-core:9903] [Proposal] Inspection using a function

[Louis Pilfold]

Heya

No polymorphic dispatch, so `result.then` as you've said. I think that is
also true of all the languages I've listed there, JavaScript's duck typing
aside.

Cheers,
Louis


On Tue, 29 Dec 2020, 13:42 José Valim,  wrote:

> Thanks Louis!
>
> Quick question: in Gleam, do you have polymorphic dispatch? Or do you have
> to do Result.then, Option.then, etc? If that's the case, then I think we
> could argue Kernel.then for identity monad and people can provide their own
> variants, as in Gleam, if they want to go down this route.
>
> I think then would only be a problem if we want to introduce a polymorphic
> monadic then in the future in Kernel.
>
> On Tue, Dec 29, 2020 at 2:26 PM Louis Pilfold  wrote:
>
>> Hello!
>>
>> As a data point JavaScript, TypeScript, Rust, Gleam, and
>> Rescript/ReasonML/Bucklescript all use then or and_then as the name for
>> that monadic function in their standard libraries.
>>
>> It seems to be a fairly common name these days so I'd probably favour
>> using a different one to avoid any confusion.
>>
>> Cheers,
>> Louis
>>
>>
>> On Tue, 29 Dec 2020, 12:30 José Valim,  wrote:
>>
>>> Hi Marten,
>>>
>>> Thanks for the feedback!
>>>
>>> The only reason I picked "then" is exactly because, if we ever introduce
>>> something akin to monads, I wouldn't pick "then" because I don't think it
>>> is clear enough on its monadic value. Also note that:
>>>
>>> 1. "andThen" in Scala is function composition and not bind. bind is
>>> flatMap (which I personally prefer)
>>>
>>> 2. "andThen" in Elm is indeed bind but it is not polymorphic, so you
>>> have Task.then, Maybe.then, etc. Therefore, even if we decide to go with
>>> "then" in the future, there is no naming conflict, unless we choose a
>>> polymorphic monad implementation. In fact, Kernel.then could then be used
>>> as an introduction to other monadic modules.
>>>
>>> So overall I think we are clear. This will be a bad choice only if all
>>> of the below are true:
>>>
>>> 1. We introduce monads
>>> 2. We pick "then" as the name for bind
>>> 3. Monads are polymorphic so we are accessing them via an imported
>>> "then" instead of qualified per module
>>>
>>> Happy holidays!
>>>
>>> On Tue, Dec 29, 2020 at 12:32 PM w...@resilia.nl  wrote:
>>>
>>>> 1. tap:
>>>> I think adding tap will be very useful. I often am doing something like
>>>>
>>>> ```
>>>> ast = quote do ... end
>>>> IO.puts(Macro.to_string(ast)
>>>> ast
>>>> ```
>>>> when debugging macros.
>>>> Being able to change this to
>>>> ```
>>>> quote do ... end
>>>> |> tap((Macro.to_string(&1))
>>>> ```
>>>> will be very welcome. :-)
>>>>
>>>> 2. then:
>>>> What José is referring to (when talking about `then` in relation to
>>>> other languages where it is also used for e.g. promises) is the monadic
>>>> 'bind' operation. You might also know it as `>>=` as well as `andThen`:
>>>> - `>>=` is the (non-descriptive) symbolic name that is used in Haskell,
>>>> PureScript, and F# as well as many papers.
>>>> - `bind` is the name given to above operation. It is also a
>>>> frequently-used name whenever an operator is not used. In fact, `bind` is
>>>> used in the Elixir ecosystem right now. One example that comes to mind is
>>>> `StreamData`. There are probably others.
>>>> - `andThen` sees usage in Scala, Elm and as already mentioned by José
>>>> in many other contexts whether they deal with only promises, only parsers,
>>>> only nondeterminism, etc... or monads in general.
>>>>
>>>> Even if it is more verbose, I think the name `andThen` is more
>>>> descriptive than plain `then`. Therefore I prefer `andThen`.
>>>>
>>>> But rather I'd not add it at all:
>>>> This proposed function will only be specialized to the "identity
>>>> monad".
>>>> The bind operation is the place where the unwrapping of the monadic
>>>> value ought to happen. The identity monad is the one case where there is
>>>> nothing to unwrap.
>>>> `then/2` as described is a function that does nothing over using the
>>>> function directly, except for "circumventing&

Re: [elixir-core:9901] [Proposal] Inspection using a function

[Louis Pilfold]

Hello!

As a data point JavaScript, TypeScript, Rust, Gleam, and
Rescript/ReasonML/Bucklescript all use then or and_then as the name for
that monadic function in their standard libraries.

It seems to be a fairly common name these days so I'd probably favour using
a different one to avoid any confusion.

Cheers,
Louis


On Tue, 29 Dec 2020, 12:30 José Valim,  wrote:

> Hi Marten,
>
> Thanks for the feedback!
>
> The only reason I picked "then" is exactly because, if we ever introduce
> something akin to monads, I wouldn't pick "then" because I don't think it
> is clear enough on its monadic value. Also note that:
>
> 1. "andThen" in Scala is function composition and not bind. bind is
> flatMap (which I personally prefer)
>
> 2. "andThen" in Elm is indeed bind but it is not polymorphic, so you have
> Task.then, Maybe.then, etc. Therefore, even if we decide to go with "then"
> in the future, there is no naming conflict, unless we choose a polymorphic
> monad implementation. In fact, Kernel.then could then be used as an
> introduction to other monadic modules.
>
> So overall I think we are clear. This will be a bad choice only if all of
> the below are true:
>
> 1. We introduce monads
> 2. We pick "then" as the name for bind
> 3. Monads are polymorphic so we are accessing them via an imported "then"
> instead of qualified per module
>
> Happy holidays!
>
> On Tue, Dec 29, 2020 at 12:32 PM w...@resilia.nl  wrote:
>
>> 1. tap:
>> I think adding tap will be very useful. I often am doing something like
>>
>> ```
>> ast = quote do ... end
>> IO.puts(Macro.to_string(ast)
>> ast
>> ```
>> when debugging macros.
>> Being able to change this to
>> ```
>> quote do ... end
>> |> tap((Macro.to_string(&1))
>> ```
>> will be very welcome. :-)
>>
>> 2. then:
>> What José is referring to (when talking about `then` in relation to other
>> languages where it is also used for e.g. promises) is the monadic 'bind'
>> operation. You might also know it as `>>=` as well as `andThen`:
>> - `>>=` is the (non-descriptive) symbolic name that is used in Haskell,
>> PureScript, and F# as well as many papers.
>> - `bind` is the name given to above operation. It is also a
>> frequently-used name whenever an operator is not used. In fact, `bind` is
>> used in the Elixir ecosystem right now. One example that comes to mind is
>> `StreamData`. There are probably others.
>> - `andThen` sees usage in Scala, Elm and as already mentioned by José in
>> many other contexts whether they deal with only promises, only parsers,
>> only nondeterminism, etc... or monads in general.
>>
>> Even if it is more verbose, I think the name `andThen` is more
>> descriptive than plain `then`. Therefore I prefer `andThen`.
>>
>> But rather I'd not add it at all:
>> This proposed function will only be specialized to the "identity monad".
>> The bind operation is the place where the unwrapping of the monadic value
>> ought to happen. The identity monad is the one case where there is nothing
>> to unwrap.
>> `then/2` as described is a function that does nothing over using the
>> function directly, except for "circumventing" the parsing precedence issue
>> of `&` vs `|>` (if you need a refresher, find prior discussion about
>> allowing anonymous functions and captures in pipes here
>> ).
>> `then/2` only exists for improved syntax, not for improved semantics.
>> The fact that we are specializing it for this single syntactic purpose
>> makes me consider that maybe we'd be better off choosing a different name
>> that does not have this pre-existing meaning attached.
>>
>> Even if you're unfamiliar with monads or algebraic datatypes in general,
>> you'll be able to understand the problem of restricting a general operation
>> to one specific case.
>> It's a bit like saying "Let's add a `Kernel.sum/1` that sums (only) lists
>> of integers." It 'works' but what about lists of floats? sets of integers?
>> lists of decimals? etc.
>> There is a lot of missed potential.
>> There is a high possibility that a decision like this cannot be extended
>> or altered later on in a backwards-compatible way.
>> There is a high likelihood of people trying to use it in contexts where
>> it cannot be used and being confused by it or introducing bugs.
>>
>>
>> So I'd seriously consider using a different naming scheme for `then`.
>> I'd prefer a simpler name with less of a pre-existing meaning.
>> Possibly just `fun/2`.
>>
>>
>> Happy holidays! :-)
>>
>> ~Marten/Qqwy
>> On Tuesday, December 29, 2020 at 10:47:17 AM UTC+1 José Valim wrote:
>>
>>> I propose we simply add two functions to Kernel: tap and then.
>>>
>>> 1. tap receives an anonymous function, invokes it, and returns the
>>> argument. It can be found in Ruby and .NET Rx.
>>>
>>> 2. then receives an anonymous function, invokes it, and returns the
>>> result of the anonymous function. It will be how we can pipe to anonymous
>>> functions in Elixir. It is named andThen in Scala and known 

Re: [elixir-core:9467] Proposal: [DDD] A new operator for making tagged tuples to express domain business rules for data of primitive types.

[Louis Pilfold]

Hiya

While I'm a big fan of editor customising I think it's important to make
technology as accessible as possible. Maybe people (most?) will not know
how to either type these characters with their keyboard or know how to
configure their editor to enter them on their behalf. Adoption will be slow
and the language will seem unfriendly if its features are not usable by all.

Cheers,
Louis


On Wed, 15 Apr 2020, 13:13 Ivan Rublev, 
wrote:

> Thanks for your comment. It may seem frustrating to use a shortcut to
> enter a symbol, especially when it's not engraved on a keyboard. Same time,
> we use shortcuts every day to speed up input.
> Emacs and Vim are enhanced editors. And I'm glad to hear that you use
> them. Emacs is very tweakable, and this is one of the brilliant properties
> of this tool that you can adjust for your comfort. F.e. adding (global-set-key
> [?\M-\q] [?\x00AB]) to the Emacs Init File gives you « symbol entered
> when you press Alt+q. And a key combination suitable for you can be
> assigned. Vim supports special symbols entered as-is coming from the OS
> input subsystem. F.e. in MacOS Vim, you can press the Alt+\ and have «
> symbol entered when in Input mode.
>
> A new operator should be easily typed in as many keyboard layouts as
> possible. Primarily because of that, these symbols « µ ¶ ¿ were suggested.
> Please, see input support for these symbols with US-international /
> UK-extended / German layouts in different OSes:
> Windows (Alt + key):
> https://sites.psu.edu/symbolcodes/windows/codeint/#foreign
> Linux (Compose key shortcuts):
> https://fsymbols.com/keyboard/linux/compose/
> macOS (Alt + key): https://fsymbols.com/keyboard/mac/
>
> On Tuesday, April 14, 2020 at 9:06:29 PM UTC+2, me wrote:
>>
>> > Is it a ridiculous idea to add one of those symbols as a new operator
>> > with the right to left associativity?
>>
>> As an Emacs (and light Vim) user, I would personally suggest against
>> something like this. At least in Emacs, it is not as simple as just
>> alt+keys in order to get these characters. And even if it were,
>> newcomers to the language, and people who rarely use these operators,
>> will have to lookup the key combination, or figure out how to do such a
>> thing in their editor.
>>
>> I would suggest that if any new operators were added to the language,
>> they should be easily typed in as many keyboard layouts as possible.
>>
>> Justin
>>
> --
> 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/f8ebb77a-540d-44d1-bbee-8efbb101d981%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-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/CABu8xFDLGqx2kZV%2BCy7jjxesVHtVqC7KSEQTy%3DFURba06SYEUw%40mail.gmail.com.

Re: [elixir-core:9285] Re: Normalize compile errors and warnings

[Louis Pilfold]

I agree there may not be any reason to introduce more formats, but Elixir
is now stable so we may want to think twice before we change any existing
output formats.

I quite like the idea of having a flag that can be given to cause all
output to be emitted in a structured format (such as JSON or the textual
Erlang term format) so it can be easily read by tooling and possibly
contain extra information that would be distracting for normal human
viewers.

Cheers,
Louis

On Wed, 27 Nov 2019 at 08:10, Mijail Rondon  wrote:

> There is not a prevention to parse both formats but also there is not a
> reason to have 2 formats.
>
> Currently to handle the warnings and errors anyone who want to do that
> have to create 2 regex to handle each one, with one format you only need
> one.
>
> I think there is not a problem if we normalize that.I'm facing that
> problem in Github Actions in this pull request:
> https://github.com/actions/setup-elixir/pull/11
> And i will be glad to make a collaboration in the core of elixir if you
> all allow me to do so.
>
> El mié., 27 de nov. de 2019 a la(s) 02:59, Louis Pilfold (lo...@lpil.uk)
> escribió:
>
>> Hello!
>>
>> What prevents the tool from attempting to parse both formats and using
>> whichever succeeds? That way this feature can exist without any changes to
>> the compiler.
>>
>> Cheers,
>> Louis
>>
>> On Wed, 27 Nov 2019, 06:11 Mijail Rondon, 
>> wrote:
>>
>>> I think i can make the change for that.
>>>
>>> Is on lib/elixir/src/elixir_errors.erl
>>>
>>> El miércoles, 27 de noviembre de 2019, 0:57:00 (UTC-5), Mijail Rondon
>>> escribió:
>>>>
>>>> Hello Elixir Core,
>>>>
>>>> Currently we have different ways to display errors or warnings during
>>>> compile time, we should normalize the output.
>>>>
>>>> For example, warnings are displayed as:
>>>>
>>>> warning: unused alias Stream
>>>>   lib/actions_sample.ex:2
>>>>
>>>> and compile errors as:
>>>>
>>>> ** (SyntaxError) lib/actions_sample.ex:15: unexpectedly reached end of
>>>> line. ...
>>>>
>>>> So, no problem with compile errors but warnings should have the same
>>>> format as:
>>>>
>>>> ** (Warning) lib/actions_sample.ex:2: unused alias Stream
>>>>
>>>> The main reason to make this change is because in CI we have the
>>>> ability of catch those warnings or errors
>>>> and add annotations on specific lines of the corresponding files.
>>>>
>>>> If we normalize the warnings this will be possible to add annotations
>>>> of warnings to.
>>>>
>>> --
>>> 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/491c2a71-560e-4df3-9547-98696502aaf8%40googlegroups.com
>>> <https://groups.google.com/d/msgid/elixir-lang-core/491c2a71-560e-4df3-9547-98696502aaf8%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
>> 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/CABu8xFDk7_z2WoqBCMAOFjNpe3kCFoQC0M0%2BkV%2BwrA4sGtttPg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/elixir-lang-core/CABu8xFDk7_z2WoqBCMAOFjNpe3kCFoQC0M0%2BkV%2BwrA4sGtttPg%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> 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/CAJ_DNyX3yPy043RsBbBKx9j-_m8B4OaofovN4dMY23gKEYj2QQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/elixir-lang-core/CAJ_DNyX3yPy043RsBbBKx9j-_m8B4OaofovN4dMY23gKEYj2QQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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/CABu8xFBY1BMp2VV3seSy0PfD0rucBWDOG-y%3DTXoqzVkdu4HHGA%40mail.gmail.com.

Re: [elixir-core:9281] Re: Normalize compile errors and warnings

[Louis Pilfold]

Hello!

What prevents the tool from attempting to parse both formats and using
whichever succeeds? That way this feature can exist without any changes to
the compiler.

Cheers,
Louis

On Wed, 27 Nov 2019, 06:11 Mijail Rondon,  wrote:

> I think i can make the change for that.
>
> Is on lib/elixir/src/elixir_errors.erl
>
> El miércoles, 27 de noviembre de 2019, 0:57:00 (UTC-5), Mijail Rondon
> escribió:
>>
>> Hello Elixir Core,
>>
>> Currently we have different ways to display errors or warnings during
>> compile time, we should normalize the output.
>>
>> For example, warnings are displayed as:
>>
>> warning: unused alias Stream
>>   lib/actions_sample.ex:2
>>
>> and compile errors as:
>>
>> ** (SyntaxError) lib/actions_sample.ex:15: unexpectedly reached end of
>> line. ...
>>
>> So, no problem with compile errors but warnings should have the same
>> format as:
>>
>> ** (Warning) lib/actions_sample.ex:2: unused alias Stream
>>
>> The main reason to make this change is because in CI we have the ability
>> of catch those warnings or errors
>> and add annotations on specific lines of the corresponding files.
>>
>> If we normalize the warnings this will be possible to add annotations of
>> warnings to.
>>
> --
> 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/491c2a71-560e-4df3-9547-98696502aaf8%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-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/CABu8xFDk7_z2WoqBCMAOFjNpe3kCFoQC0M0%2BkV%2BwrA4sGtttPg%40mail.gmail.com.

Re: [elixir-core:9175] Detecting bogus defdelegate options

[Louis Pilfold]

Hello!

What would be the desired behaviour of the `when` option?

Cheers,
Louis

On Wed, 16 Oct 2019 at 10:51, Thomas Stratmann <
thomas.stratm...@9elements.com> wrote:

> Hello,
>
> a coworker tried `defdelegate fun(..), to: SomeModule, when:
> some_conditon` the other day. defdelegate does not implement a `when`
> option, but does not complain about any excess options.
>
> Since defdelegate is almost always executed at compile time, the impact of
> an additional check for the options passed should be negligible. It could
> raise with a meaningful message.
>
> Would this be a welcome change?
>
> --
> 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/8856eeed-f80e-458a-addb-e063e9791473%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-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/CABu8xFAsR95xcnv1ZbwinA3cq_qZJGS8GqARe42u9R%3DJ-Vx4Gg%40mail.gmail.com.

Re: [elixir-core:9128] Suggestion Add Rubys tally

[Louis Pilfold]

I'm a native English speaker and count_by is clearer to me than tally,
which I would think of as a way of counting using tally marks without any
relation to grouping items before counting.

I also like that the name count_by matches group_by, which has similar
behaviour.

Cheers,
Louis

On Sat, 5 Oct 2019, 16:18 Greg Vaughn,  wrote:

> "Tally" is not used often, but it does precisely and concisely describe
> the function. For more reference, those 4 vertical lines with a slash
> across them to represent 5 are known as "tally marks" (see
> https://en.wikipedia.org/wiki/Tally_marks). Also, if this were in our
> standard library, I would always think of Harry Belafonte's _Day-O_ song
> and smile when I use it ("come mister tally man, tally me banana") (
> https://www.youtube.com/watch?v=6Tou8-Cz8is)
>
> -Greg Vaughn
>
> > On Oct 4, 2019, at 7:55 PM, José Valim 
> wrote:
> >
> > So I am not a native speaker, but “tally” sounds very foreign to me. Is
> it used frequently? I am afraid an uncommon name won’t help with
> readability/discovery. Is there a reason why it is not called count_by? It
> seems it was first proposed as such to Ruby. Thank you for the proposal!
> > --
> >
> >
> > José Valim
> > www.plataformatec.com.br
> > Skype: jv.ptec
> > Founder and Director of R
> >
> > --
> > 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/CAGnRm4KqUJKyuD0CSe5gTHL761SR6CncKDD1ryTsHTuRWXFN8g%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/A87FBBAC-8F1E-450D-B844-A02F2F7A71B6%40gmail.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/CABu8xFCxsWMVW5AGMu0KuoQw1MtugkMvuUhi452p37V9Jpp2jQ%40mail.gmail.com.

Re: [elixir-core:8945] Re: [Proposal] identity function

[Louis Pilfold]

Hi Alexey

In this mailing list and in the Elixir community in general we want to
create a friendly and welcoming environment. Please refrain from calling
people's opinions "insane" and try to be respectful of others.

For more information please read the Elixir code of conduct
https://github.com/elixir-lang/elixir/blob/master/CODE_OF_CONDUCT.md

Thanks,
Louis


On Thu, 18 Jul 2019, 13:26 Alexey Nikitin,  wrote:

> What's wrong with you? What planet are you from? Any functional language
> has this function. These are basic concepts of mathematics and functional
> programming. What a "slippery slope"? It's insane. This function just must
> to be here, that's all. The standard library has `fn x -> x end`
> everywhere. So if you didn't know, this thing has a name!
>
> воскресенье, 14 июля 2019 г., 18:34:36 UTC+3 пользователь Chris Keathley
> написал:
>>
>> I understand that the desire from the core team isn't to add this. I'm OK
>> with that decision despite feeling like it would be a good addition That's
>> fine.
>>
>> But I do take issue with this "slippery slope" argument that adding
>> `identity` to Elixir would somehow open the door to numerous other
>> functions being added to Elixir. Which is silly. Because we aren't talking
>> about adding some untold number of functions to Elixir. We're talking about
>> `identity`. If the core team had decided that `identity` was worth having
>> in the language would we still not add it because later someone could add
>> the `snausages` function? No. Of course not. That's a nonsensical argument.
>> Improvements to the language should be considered on their own terms.
>>
>> On Sat, Jul 13, 2019 at 12:26 AM Sven Gehring  wrote:
>>
>>> I definitely agree that it's better to import it from an additional
>>> module if need be.
>>>
>>> If we ignore the Metaprogramming parts, Elixir has a very easy Syntax
>>> and the &(&1) notation is one of the only non-intuitive things to learn.
>>> Compared to other languages, there are virtually no 'weird' syntax elements
>>> you have to 'just remember' when you start out, so I am actually in favor
>>> of teaching people this shorthand instead of hiding it from them. (It's
>>> really not THAT complicated)
>>>
>>> Also, as José said, you can always use "fn x -> x end", which is about
>>> the same length as "/1" and also obvious in what it does.
>>>
>>> I don't think expanding the Kernel just for the sake of adopting
>>> concepts of similar ecosystems is worth it.
>>>
>>> Sven
>>>
>>> On Fri, Jul 12, 2019, 23:10 Rich Morin  wrote:
>>>
 > On Jul 12, 2019, at 13:43, José Valim 
 wrote:
 >
 > Filtering nils may be considered bad practice (i.e. why do you have
 nils there?)

 I use them, on occasion, to support a "maybe" type.

 > ... it may be more readable to do with Enum.reject(_nil/1).

 Cool!  I just replaced four instances of `Enum.filter(&(&1))` with
 `Enum.reject(_nil/1)`.
 FWIW, I'd love to see an annotated collection of suggested Elixir
 idioms such as this one.

 -r

 --
 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/C4BDFC3F-1646-4957-B814-0204D3B147A6%40gmail.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-l...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/elixir-lang-core/CAFuVuxzkdQbPZaPHRWA6w13LE1jFZm-sgoxK8ToOkTag2_9AbA%40mail.gmail.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> --
>> Chris
>>
> --
> 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/aa6ad3d9-abc6-4afb-b153-26491d3cc6b4%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 

Re: [elixir-core:8891] [Notions] extend function capture syntax

[Louis Pilfold]

Hiya

Given Elixir has very limited ability to infer information at compile time
how will the compiler know which function to capture? It is not possible to
create a multiple-arity anonymous function on the BEAM.

Cheers,
Louis


On Tue, 2 Jul 2019, 17:52 Rich Morin,  wrote:

> I enjoyed reading "[elixir-core:8881] [Proposal] identity function" and the
> ensuing discussion.  It strikes me that some simple extensions to Elixir's
> function capture syntax might:
>
> - clean up the appearance of function captures
> - make existing functions more generally useful
> - reduce the need for special-purpose lambdas
>
> When a captured function is being used as an argument, it may be possible
> to infer its arity.  So, maybe we can leave this out:
>
>   Enum.map()
>   Enum.sort_by()
>
> Many named functions take multiple arguments, so they can't be used in
> function captures.  Allowing arguments could extend their reach:
>
>   Enum.sort_by((1))  # sort by the 2nd element
>   Enum.map((42)) # append 42 to each tuple
>
> On a loosely related note, Clojure gets a lot of mileage out of some
> higher-order abstractions (eg, seqs).  There may be opportunities for
> Elixir to follow their lead.  For example, some Enum and List functions
> might be applicable to Tuples.  Similarly, String functions such as
> downcase/1 could be extended to accept atoms, etc.
>
> (ducks)
>
> -r
>
> --
> 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/3A20E4BD-9648-4872-852A-C5FFDD0A31D5%40gmail.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/CABu8xFAw8okEXjoPkEko1kpy2t6FCv%2BSrGsagxNVARHjFHPSfA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:8752] Disable regex precompilation

[Louis Pilfold]

I see! The first email here said deps was a problem so I was going with
that. I'm glad a solution has been found :)

On Fri, 10 May 2019, 22:07 José Valim, 
wrote:

> > This approach would mean that any library that uses an regex signal
> could not be used in the application as they may not work on other Erlang
> versions. Is that right?
>
> It is correct. Elixir for example wraps its regexes in the same
> Regex.recompile block. But according to the previous discussion in the
> issues tracker they are not concerned with dependencies.
>
> *José Valim*
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Director of R
>
>
> On Fri, May 10, 2019 at 11:05 PM Louis Pilfold  wrote:
>
>> I'm not sure a linter would help here as it could only be applied to your
>> app code, not that of libraries.
>>
>> This approach would mean that any library that uses an regex signal could
>> not be used in the application as they may not work on other Erlang
>> versions. Is that right?
>>
>> On Fri, 10 May 2019, 20:05 José Valim, 
>> wrote:
>>
>>> There is no compiler option that changes the code behavior. It is a
>>> global configuration, which can make debugging and understanding the system
>>> hard. We would need a strong precedent to add it.
>>>
>>> Given the current problem has existing solutions today, all you need to
>>> do is to wrap the regex, I still think having a linter that guarantees all
>>> regexes have been wrapped is IMO the best call. So all we need is a flag to
>>> disable the endianess check.
>>> --
>>>
>>>
>>> *José Valim*
>>> www.plataformatec.com.br
>>> Skype: jv.ptec
>>> Founder and Director of R
>>>
>>> --
>>> 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%2BNDVa%2BG0XH-21UWu9BU-%2BJnnED55XQaRjncKp1qowRXw%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BNDVa%2BG0XH-21UWu9BU-%2BJnnED55XQaRjncKp1qowRXw%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/CABu8xFBWUP4OzeVc9tWA2jfcjijPV8JzbFq-1sxHiTCS-yR0dg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/elixir-lang-core/CABu8xFBWUP4OzeVc9tWA2jfcjijPV8JzbFq-1sxHiTCS-yR0dg%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/CAGnRm4KqdR%2BNq9kMs61gaUfAH%2BrXW9E5Y9FyVQSEwZ-paDzJ9w%40mail.gmail.com
> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4KqdR%2BNq9kMs61gaUfAH%2BrXW9E5Y9FyVQSEwZ-paDzJ9w%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/CABu8xFChABdeXKbwRHLhKob2BXSV11hnfU%3DdFUdwgYXEgnRwYw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:8749] Disable regex precompilation

[Louis Pilfold]

I'm not sure a linter would help here as it could only be applied to your
app code, not that of libraries.

This approach would mean that any library that uses an regex signal could
not be used in the application as they may not work on other Erlang
versions. Is that right?

On Fri, 10 May 2019, 20:05 José Valim, 
wrote:

> There is no compiler option that changes the code behavior. It is a global
> configuration, which can make debugging and understanding the system hard.
> We would need a strong precedent to add it.
>
> Given the current problem has existing solutions today, all you need to do
> is to wrap the regex, I still think having a linter that guarantees all
> regexes have been wrapped is IMO the best call. So all we need is a flag to
> disable the endianess check.
> --
>
>
> *José Valim*
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Director of R
>
> --
> 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%2BNDVa%2BG0XH-21UWu9BU-%2BJnnED55XQaRjncKp1qowRXw%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/CABu8xFBWUP4OzeVc9tWA2jfcjijPV8JzbFq-1sxHiTCS-yR0dg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:8617] Re: Give warning on unused require

[Louis Pilfold]

Hey

Wouldn't it be possible to track if any macros have been used by the
requiring module? I'm not familiar with the compiler here but it seems like
it is always possible as all information is available at compile time.

Cheers,
Louis

On Mon, 8 Apr 2019, 09:19 Łukasz Niemier,  wrote:

> Not possible as `require`s are *always* used - by the compiler, as this
> marks that required module need to be compiled before compilation of module
> with require.
>
> W dniu piątek, 5 kwietnia 2019 17:48:56 UTC+2 użytkownik Mário Guimarães
> napisał:
>>
>> Hi,
>>
>> I suggest for Elixir to warn on unused requires, like it does for unused
>> aliases.
>>
>> Thanks
>>
> --
> 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/57e4a930-f4f2-4efa-a0bf-35f470a652a6%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/CABu8xFBrM7LuJoZT0HzPQ-ifxOSgVZT03XwRu%3D-pC%3DQ%3D5Ow21Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:8609] Missing tuple access idioms

[Louis Pilfold]

Hey

We have elem/2, which is quite clear and more concise.

We don't need specific functions for each index because we are not limited
by a static type system and so the index does not need to be known at
compile time.

Cheers,
Louis

On Fri, 5 Apr 2019, 11:29 Mário Guimarães, 
wrote:

> Hello,
>
> any reason why there are no easy readable idioms like
>
> first, snd, third, ..., tenth (I guess is enough)
>
> to access tuples?
>
> Thanks
>
> --
> 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/75b06fc7-5be0-4070-8c49-6e2fb5779ea3%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/CABu8xFC00eHW29-46dMr%3DbERc_CP-4OAp2pgntuCCgtevm%2Bt5g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:8537] [Proposal] Simplify @spec def and @spec defp for efficiency and maintenance purpose

[Louis Pilfold]

Hi

As Elixir has reached version 1 there's not going to be a major change of
syntax like this.

You could implement this as a macro in your own project though :)


use MyMacro

def add(x :: number(), y :: number()) :: number() do
  x + y
end


Cheers,
Louis

On Wed, 13 Mar 2019, 08:34 ,  wrote:

> Instead of doing this:
>
> defmodule LousyCalculator do
>   @spec add(number, number) :: {number, String.t}
>   def add(x, y), do: {x + y, "You need a calculator to do that?!"}
>
>   @spec multiply(number, number) :: {number, String.t}
>   def multiply(x, y), do: {x * y, "Jeez, come on!"}
> end
>
>
>
> How about this:
>
> defmodule LousyCalculator do
>
>   @specdef add(x number, y number) :: {number, String.t} do: {x + y, "You 
> need a calculator to do that?!"}
>   @specdef multiply(x number, y number) :: {number, String.t} do:   {x * y, 
> "Jeez, come on!"}
> end
>
> --
> 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/ac230011-82c2-4c44-8c4b-58fd163ec081%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/CABu8xFACGGkm8GtEKQPxog4X4AEjkwUim_aXRWZMwQXJvdxEpg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:8529] [Proposal] Double pipeline operator ||>

[Louis Pilfold]

Hi Tom!

While it will not be added to core there is no reason why you couldn't
implement this functionality in your application or as a library.

Elixir does allow custom operators, though the ones you can use is limited
so you won't be able to use `||>` `|||>` etc. Perhaps instead your macro
could use a placeholder to indicate where the value should be inserted:

   data |> File.write!(path, _)

or

   data >>> File.write!(path, _)

Cheers,
Louis

On Sun, 10 Mar 2019 at 09:45 José Valim 
wrote:

> Hi Tom,
>
> Extensions to the pipe operator have been proposed multiple times and
> always rejected. I recommend reading previous discussions for more
> information.
>
> Have a good one,
>
>
> *José Valim*
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Director of R
>
>
> On Sun, Mar 10, 2019 at 10:37 AM  wrote:
>
>> The pipeline operator is one of the best features of the language,
>> however there are some instances where you want to continue a chain of
>> pipelines for clarity but can't because the argument order is not conducive
>> to piping. For example here is an example when working with files:
>>
>> defmodule Chess.PGN do
>>   def unique_checkmates(input_path, output_path)
>> path
>> |> File.stream!()
>> |> Stream.chunk_every(21)
>> |> Stream.filter(fn chunk -> checkmate?(Enum.at(chunk, 17)) end)
>> |> Stream.uniq_by(fn chunk -> Enum.at(chunk, 19) end)
>> |> Stream.map(fn chunk -> Enum.join(chunk, "") end)
>> |> Enum.join("")
>> |> write_file(output_path)
>>   end
>>
>>   def write_file(content, output_path) do
>> File.write!(output_path, content)
>>   end
>> end
>>
>> Instead of having to add a dummy method I would like to double pipe into
>> File.write which would be cleaner.
>>
>>   ...
>>   ||> File.write!(output_path)
>>
>> I think this could also be extended to triple, and quadruple pipes. Five
>> seems like overkill, but I think you could make the argument for arbitrary
>> levels of piping.
>>
>> --
>> 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/c6f02f27-fca4-4d5b-9c88-e966faaf9c0c%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/CAGnRm4%2BVArZWX%3DBjnU%3DvB5ZZ8%2Bwk8_Ff2MqL8nG7_sjbQRheig%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/CABu8xFBh_RrNCTjBPNyaDPj7Uw3xX3uhFYNssynemb%3D8Qg5tww%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:8449] [Proposal] In DynamicSupervisor, process terminations asynchronously.

[Louis Pilfold]

Hi Derek

Why not spawn a new process and call DynamicSupervisor.terminate_child from
there? Perhaps using the Task module.

For me this would be preferable to making an async version of the function
as (in addition to keeping the DynamicSupervisor API simple) it leaves it
up to the caller to decide how the timeout should handled (should we crash,
retry, or discard the error?), and whether there should be a notification
of some kind when the call has succeeded.

Cheers,
Louis

On Tue, 15 Jan 2019 at 10:29 Derek Kraan  wrote:

> Currently, a call to DynamicSupervisor.terminate_child waits until the
> process has exited (or the shutdown times out) before processing any other
> messages. This can take up to `shutdown` milliseconds, which could be a
> long time depending on what the application has configured.
>
> I have run into this problem before in my work, and solved it in my
> project by ensuring that a process is in a "ready to terminate" state
> before asking the DynamicSupervisor to terminate it. This works for us, but
> we have to be really careful with this and if we make a mistake it could
> have a huge performance impact.
>
> After reading the code, I think it is possible to process these
> terminations asynchronously. This would allow other work (including process
> restarts, starting new processes, terminating other processes) to continue
> unimpeded.
>
> The downside is that the DynamicSupervisor would get more complex. The
> upside is that we could solve a potentially big performance bottleneck in
> people's apps.
>
> Is this a change that would be considered?
>
> --
> 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/0bab277d-588e-4901-ba82-fe82375db301%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/CABu8xFBFa38ROVYtJ4sHSJGAK9XuYqzYsVW6m1XJAiROt4%2Bjog%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:8444] [Proposal] Map.drop : friendlier error message if atom given instead of list

[Louis Pilfold]

Hi

Perhaps the error message for an unimplemented protocol could be made more
friendly. I don't have any suggestions myself, but perhaps Edouard had some
ideas for Map.drop that could be generalised to all protocols.

Cheers,
Louis

On Sun, 13 Jan 2019, 12:02 José Valim, 
wrote:

> It would be possible only if you manually write error messages for every
> existing function. There is no trivial way to automate it without adding a
> type system.
>
>
> *José Valim*
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Director of R
>
>
> On Sun, Jan 13, 2019 at 12:42 PM Edouard Mnd 
> wrote:
>
>> Oh i see so the only simple option would be to add something along the
>> line `drop(map, a) when is_atom(a)` but it would mean making the widening
>> the api surface.
>> Maybe the answer does not lie directly in elixir core but in something
>> that would run after the elixir compiler able to give suggestions about the
>> errors ? It clearly is not the scope of the discussion but I would be
>> interested to know what you think about it and what elixir api could be
>> used to make such a hint/suggestion layer.
>>
>> On Saturday, January 12, 2019 at 8:38:20 PM UTC+1, Andrea Leopardi wrote:
>>>
>>> The problem here is that Map.drop/2 expects a term as the second
>>> argument that implements the Enumerable protocol. This means that
>>> realistically we can't check for a specifically supported data type or
>>> types, since anything could implement the Enumerable protocol. For example,
>>> I might implement Enumerable for atoms and then your code would work.
>>>
>>> On Sat, 12 Jan 2019 at 19:10, Edouard Mnd  wrote:
>>>
  Hi,

 I have been running into the same issue again and again with elixir
 where I get a weird error like

> (Protocol.UndefinedError) protocol Enumerable not implemented for
> "foo". This protocol is implemented for: DBConnection.PrepareStream, DBCo
> nnection.Stream, Date.Range, Ecto.Adapters.SQL.Stream, File.Stream,
> Function, GenEvent.Stream, HashDict, HashSet, IO.Stream, List, Map, 
> MapSet,
> Postgr ex.Stream, Range, Stream, StreamData, Timex.Interval
>
 when doing `Map.drop(foo, :sth).
 Obviously i'm doing something wrong : I should give a list as a second
 argument but I keep forgetting and I bet i'm not the only one.
 My proposal would consist in handling this case explicitly either by
 allowing for such a case to work or giving back a clear error message such
 as "Are you trying to do Map.drop(foo,[:sth]) ?".
 I'm greatly inspired by the rust language in asking this, indeed rust
 gives you really great error messages when doing silly things.

 I hope you find my proposal clear and interesting as it clearly is not
 just about Map.drop but also about giving better error messages to the
 developer when doing silly things which I think is important.

 --
 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/550f8801-c0d9-41ea-947a-8c3ee483c76a%40googlegroups.com
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>> --
>>>
>>> Andrea Leopardi
>>> an.le...@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/93fd3c38-c285-48b8-87d1-898fe45a1afc%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/CAGnRm4%2BUJwM4cyif%2ByBtRyge6mJ-uR%3DAiJuFkJnnazyN6-JQ-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 

Re: [elixir-core:8428] [Proposal] Deprecate unless-else

[Louis Pilfold]

I might be wrong, but I think the formatter already updates the AST in some
places to fix deprecation warnings.

On Fri, 4 Jan 2019, 00:57 eksperimental, 
wrote:

> On Fri, 4 Jan 2019 07:54:44 +0700
> eksperimental  wrote:
>
> > On Thu, 3 Jan 2019 11:25:13 -0800
> > Ryan Winchester  wrote:
> > > Have the formatter change it to an if/else , or just leave it for
> tools
> > > like Credo to yell at you for an unless/else.
> >
> > This is definitely something the formatter should do.
> SHOULD NOT DO!
>
> --
> 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/20190104075710.7cb95c4f.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/CABu8xFDwh37nVYno5BCBqsu0US90EyM_GXwwh_ErefoEA%2B3UCg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:8400] Re: Proposal: Inspect for records

[Louis Pilfold]

Hey

Unlike structs there's no guarantee that two records won't be defined with
the same name, they are scoped within modules.

Cheers,
Louis

On Sun, 16 Dec 2018 at 13:55 Allen Madsen  wrote:

> Couldn't you define a method like __record_keys__/0 on the atom in the
> defrecord call?
>
> Allen Madsen
> http://www.allenmadsen.com
>
>
> On Sat, Dec 15, 2018 at 11:49 AM  wrote:
>
>> One way to avoid issues with state is to avoid... state. Maybe we'd
>> configure it like this:
>>
>> records = [
>>   # explicit
>>   {:column_definition, [:name, :type]},
>>
>>   # grabs record fields from record macro in that module, e.g:
>> resultset(resultset()) |> Keyword.keys()
>>   {Records, :resultset}
>> ]
>>
>> IEx.configure(inspect: [records: records])
>> ExUnit.configure(inspect: [records: records])
>>
>> This is less convenient, but I guess sometimes we may prefer the "tuple"
>> representation so by making this opt-in we cater to that use case as well.
>>
>> On Saturday, December 15, 2018 at 5:08:13 PM UTC+1,
>> wojte...@plataformatec.com.br wrote:
>>>
>>> Hello,
>>> I'd like to discuss support for Inspect protocol for records. I created
>>> a proof-of-concept here: https://github.com/wojtekmach/record_inspect
>>>
>>> Basically, for these records:
>>>
>>> defrecord :resultset [
>>>   :column_count,
>>>   :column_definitions,
>>>   :row_count,
>>>   :rows,
>>>   :warning_count,
>>>   :status_flags
>>> ]
>>>
>>> defrecord :column_definition41, [:name, :type]
>>>
>>> Instead of:
>>>
>>> {:resultset, 2,
>>>  [{:column_definition41, "2*3", 8}, {:column_definition41, "4*5", 8}], 1
>>> ,
>>>  [[6, 20]], 0, 2}
>>>
>>> We could get this:
>>>
>>> #resultset([
>>>   column_count: 2,
>>>   column_definitions: [
>>> #column_definition41([name: "2*3", type: 8]),
>>> #column_definition41([name: "4*5", type: 8])
>>>   ],
>>>   row_count: 1,
>>>   rows: [[6, 20]],
>>>   warning_count: 0,
>>>   status_flags: 2
>>> ])
>>>
>>> My proof-of-concept uses the new `:persistent_term` facility in OTP 21.2
>>> just to get something working. Managing the state is challenging for
>>> potentially including this in Elixir.
>>>
>>> Feedback appreciated!
>>>
>> --
>> 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/8e936469-e806-46f9-b4a4-3aa3c577d205%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/CAK-y3Ct-2iFCY12qQD07GurkkRepiN3vqaDVgML_7WpHctqLuA%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/CABu8xFAA1LjjKE2O16VhmYsA87ykR88FgCa_1hbCJggPA-1pVg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:8386] Re: Enum.sum/2

[Louis Pilfold]

Hi

If this function were to exist I think we would need to call it
`sum_map/2`, as the combination of `sum` and `map`. Previously we had
`Enum.filter_map/2`, though it was deprecated in favour of `Enum.filter/2`
and `Enum.map/2`. The trend is that we are removing these combined Enum
functions rather than adding them, so it seems unlikely that we would add
this new kind of `sum` if we continued this debate.

A good point from Ben, the polymorphic nature of Enum and the Enumerable
protocol means it is slower than using the List module or writing recursive
functions, so for this kind of performance tuning the Enum module is
probably not the right place to start.

Cheers,
Louis

On Mon, 3 Dec 2018 at 02:19 Ben Wilson  wrote:

> 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
> to avoid the second pass then you want a bare recursive function anyway and
> shouldn't even use Enum.
>
> On Saturday, December 1, 2018 at 11:18:58 AM UTC-5, Sean Handley wrote:
>>
>> Hello,
>>
>> I'd like to propose *Enum.sum/2*, where the second argument is a
>> function.
>>
>> This will allow writing
>>
>> Enum.sum([1, 2, 3], &(&1 * 2))
>>
>> instead of
>>
>> Enum.map([1,2,3], &(&1 * 2)) |> Enum.sum()
>>
>> The advantages are:
>>
>> - Write less code.
>> - One few iteration across the collection.
>>
>> I have a branch prepared -
>> https://github.com/elixir-lang/elixir/compare/master...seanhandley:map_with_func
>>
>> Please let me know your thoughts.
>>
>> Cheers,
>> Sean
>>
>> --
> 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/fb7ab97c-3b0d-4772-9525-617cc765414a%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/CABu8xFBEb-%3DuO4Ft3q1SVnpedyByOJKZ_w9CYRE2tawQhVY%3DHw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Louis Pilfold]

Hey

I don't believe that exists, at least not in the standard distribution.
Perhaps there is a library that provides this functionality.

Cheers,
Louis

On Wed, 7 Nov 2018, 23:05 Sergiy Kukunin,  wrote:

> Thanks for the explanation about guards, makes sense. And I totally agree
> with you, that can be implemented as an assertion at the very begin of
> function's body.
>
> Again, the question - is there a way to leverage typespecs? Is there a way
> to implement something like this "hey elixir, is this value corresponds to
> this type?"
> I'd like to avoid a custom way to define specs for that assertions macros.
>
> On Thu, Nov 8, 2018 at 12:58 AM Louis Pilfold  wrote:
>
>> Hey
>>
>> The implementation you've given there is expensive and only works for
>> lists up to a certain length.
>>
>> To solve this one you'll need to step outside of guard clauses as they
>> only support a limited subset of Elixir/Erlang. The idea is that all
>> operations in guards are very fast and run in constant time, so iterating
>> over a list or arbitrary length is not supported.
>>
>> Another option would be to write a macro that prepends a type checking
>> statement to a function body, asserting that the arguements are of the
>> correct type.
>>
>> Cheers,
>> Louis
>>
>> On Wed, 7 Nov 2018, 22:41 Sergiy Kukunin, 
>> wrote:
>>
>>> Found another problem: can't express "list of strings" in guards nor
>>> pattern matching. It's an easy task for typespecs `[String.t(), ...]`, but
>>> I can't check typespecs in runtime. Found a very dirty hack, that works for
>>> lists up to 5 strings, enjoy:
>>>
>>>   defguardp is_list_of_strings(x)
>>> when (length(x) == 1 and is_binary(hd(x)))
>>> or (length(x) == 2 and is_binary(hd(x)) and is_binary(hd(tl(x
>>> or (length(x) == 3 and is_binary(hd(x)) and is_binary(hd(tl(x))) and
>>> is_binary(hd(tl(tl(x)
>>> or (length(x) == 4 and is_binary(hd(x)) and is_binary(hd(tl(x))) and
>>> is_binary(hd(tl(tl(x
>>> and is_binary(hd(tl(tl(tl(x))
>>> or (length(x) == 5 and is_binary(hd(x)) and is_binary(hd(tl(x))) and
>>> is_binary(hd(tl(tl(x
>>> and is_binary(hd(tl(tl(tl(x) and
>>> is_binary(hd(tl(tl(tl(tl(x)))
>>>
>>> Wouldn't it be cool to be able to write something like
>>>
>>> defguard is_list_of_strings(x) match_type([String.t(), ...])
>>>
>>> Again, I'm pretty new, and I know nothing about the implementation and
>>> where Elixir ends and Erlang starts, and how feasible it is. Just an idea
>>> =)
>>>
>>> On Wed, Nov 7, 2018 at 10:11 PM Sergiy Kukunin 
>>> wrote:
>>>
>>>> Actually, that what I understood only in my last message - I can
>>>> implement it right now. I'm pretty new to Elixir, so that wasn't obvious to
>>>> me.
>>>>
>>>> Currently, it seems it's resolved, there are only suggestions to
>>>> improve syntax, that are too minor.
>>>>
>>>> Thank everyone for assistance
>>>>
>>>> On Wed, Nov 7, 2018 at 9:15 PM Louis Pilfold  wrote:
>>>>
>>>>> Hi Sergiy
>>>>>
>>>>> I'm afraid I don't follow. From what I understand of your proposal the
>>>>> current defguard system meets your needs- what are you looking to add?
>>>>>
>>>>> Cheers,
>>>>> Louis
>>>>>
>>>>> On Wed, 7 Nov 2018 at 18:38 Sergiy Kukunin 
>>>>> wrote:
>>>>>
>>>>>> I afraid you missed my point, I might have expressed it poorly. Let's
>>>>>> assume I have a simple type: {is_atom(), is_number(), is_binary()}. I 
>>>>>> want
>>>>>> to define a guard to match it. Without reusing I can write a function
>>>>>> accepting it:
>>>>>>
>>>>>> func({x, y, z}) when is_atom(x) and is_number(y) and is_binary(z),
>>>>>> do: true
>>>>>>
>>>>>> but then I want to define another function which expects the same
>>>>>> tuple:
>>>>>>
>>>>>> another({x, y, z}) when is_atom(x) and is_number(y) and is_binary(z),
>>>>>> do: true
>>>>>>
>>>>>> I don't have a way to define a custom guard to match tuple elements
>>>>>> since there is no pattern matchi

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

[Louis Pilfold]

Hey

The implementation you've given there is expensive and only works for lists
up to a certain length.

To solve this one you'll need to step outside of guard clauses as they only
support a limited subset of Elixir/Erlang. The idea is that all operations
in guards are very fast and run in constant time, so iterating over a list
or arbitrary length is not supported.

Another option would be to write a macro that prepends a type checking
statement to a function body, asserting that the arguements are of the
correct type.

Cheers,
Louis

On Wed, 7 Nov 2018, 22:41 Sergiy Kukunin,  wrote:

> Found another problem: can't express "list of strings" in guards nor
> pattern matching. It's an easy task for typespecs `[String.t(), ...]`, but
> I can't check typespecs in runtime. Found a very dirty hack, that works for
> lists up to 5 strings, enjoy:
>
>   defguardp is_list_of_strings(x)
> when (length(x) == 1 and is_binary(hd(x)))
> or (length(x) == 2 and is_binary(hd(x)) and is_binary(hd(tl(x
> or (length(x) == 3 and is_binary(hd(x)) and is_binary(hd(tl(x))) and
> is_binary(hd(tl(tl(x)
> or (length(x) == 4 and is_binary(hd(x)) and is_binary(hd(tl(x))) and
> is_binary(hd(tl(tl(x
> and is_binary(hd(tl(tl(tl(x))
> or (length(x) == 5 and is_binary(hd(x)) and is_binary(hd(tl(x))) and
> is_binary(hd(tl(tl(x
> and is_binary(hd(tl(tl(tl(x) and
> is_binary(hd(tl(tl(tl(tl(x)))
>
> Wouldn't it be cool to be able to write something like
>
> defguard is_list_of_strings(x) match_type([String.t(), ...])
>
> Again, I'm pretty new, and I know nothing about the implementation and
> where Elixir ends and Erlang starts, and how feasible it is. Just an idea
> =)
>
> On Wed, Nov 7, 2018 at 10:11 PM Sergiy Kukunin 
> wrote:
>
>> Actually, that what I understood only in my last message - I can
>> implement it right now. I'm pretty new to Elixir, so that wasn't obvious to
>> me.
>>
>> Currently, it seems it's resolved, there are only suggestions to improve
>> syntax, that are too minor.
>>
>> Thank everyone for assistance
>>
>> On Wed, Nov 7, 2018 at 9:15 PM Louis Pilfold  wrote:
>>
>>> Hi Sergiy
>>>
>>> I'm afraid I don't follow. From what I understand of your proposal the
>>> current defguard system meets your needs- what are you looking to add?
>>>
>>> Cheers,
>>> Louis
>>>
>>> On Wed, 7 Nov 2018 at 18:38 Sergiy Kukunin 
>>> wrote:
>>>
>>>> I afraid you missed my point, I might have expressed it poorly. Let's
>>>> assume I have a simple type: {is_atom(), is_number(), is_binary()}. I want
>>>> to define a guard to match it. Without reusing I can write a function
>>>> accepting it:
>>>>
>>>> func({x, y, z}) when is_atom(x) and is_number(y) and is_binary(z), do:
>>>> true
>>>>
>>>> but then I want to define another function which expects the same tuple:
>>>>
>>>> another({x, y, z}) when is_atom(x) and is_number(y) and is_binary(z),
>>>> do: true
>>>>
>>>> I don't have a way to define a custom guard to match tuple elements
>>>> since there is no pattern matching in defguard nor there is `elem` in
>>>> guards. So both options don't work:
>>>>
>>>> defguard is_mytype({x, y, z}) when is_atom(x) and is_number(y) and
>>>> is_binary(z)
>>>>
>>>> nor
>>>>
>>>> defguard is_mytype(x) when is_atom(elem(x, 0)) and is_number(elem(x,
>>>> 1)) and is_binary(elem(x, 2))
>>>>
>>>> Furthermore, I would want to define a function that receives a value of
>>>> my type inside of complex structure:
>>>>
>>>> function({:ok, {x, y, z}}) when is_atom(x) and is_number(y) and
>>>> is_binary(z), do: true
>>>>
>>>> it would be cool to have it defined as
>>>>
>>>> function({:ok, x}) when is_mytype(x), do: true
>>>>
>>>> P.S. Actually, I've found that `elem` works in guards, so I can define
>>>> my guard without pattern matching. That's good for now, but
>>>>
>>>> func({x, y, z}) when is_atom(x) and is_number(y) and is_binary(z), do:
>>>> true
>>>>
>>>> sounds cooler, IMHO =)
>>>>
>>>> On Wednesday, November 7, 2018 at 8:20:22 PM UTC+2, Louis Pilfold wrote:
>>>>
>>>>> Hi Sergiy
>>>>>
>>>>> The functionality you've described can be implemented wi

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

[Louis Pilfold]

Hi Sergiy

I'm afraid I don't follow. From what I understand of your proposal the
current defguard system meets your needs- what are you looking to add?

Cheers,
Louis

On Wed, 7 Nov 2018 at 18:38 Sergiy Kukunin  wrote:

> I afraid you missed my point, I might have expressed it poorly. Let's
> assume I have a simple type: {is_atom(), is_number(), is_binary()}. I want
> to define a guard to match it. Without reusing I can write a function
> accepting it:
>
> func({x, y, z}) when is_atom(x) and is_number(y) and is_binary(z), do: true
>
> but then I want to define another function which expects the same tuple:
>
> another({x, y, z}) when is_atom(x) and is_number(y) and is_binary(z), do:
> true
>
> I don't have a way to define a custom guard to match tuple elements since
> there is no pattern matching in defguard nor there is `elem` in guards. So
> both options don't work:
>
> defguard is_mytype({x, y, z}) when is_atom(x) and is_number(y) and
> is_binary(z)
>
> nor
>
> defguard is_mytype(x) when is_atom(elem(x, 0)) and is_number(elem(x, 1))
> and is_binary(elem(x, 2))
>
> Furthermore, I would want to define a function that receives a value of my
> type inside of complex structure:
>
> function({:ok, {x, y, z}}) when is_atom(x) and is_number(y) and
> is_binary(z), do: true
>
> it would be cool to have it defined as
>
> function({:ok, x}) when is_mytype(x), do: true
>
> P.S. Actually, I've found that `elem` works in guards, so I can define my
> guard without pattern matching. That's good for now, but
>
> func({x, y, z}) when is_atom(x) and is_number(y) and is_binary(z), do:
> true
>
> sounds cooler, IMHO =)
>
> On Wednesday, November 7, 2018 at 8:20:22 PM UTC+2, Louis Pilfold wrote:
>
>> Hi Sergiy
>>
>> The functionality you've described can be implemented with macros, no
>> need to modify Elixir or Erlang.
>>
>> To start it could be as simple as defining guards that assert nothing in
>> the production environment.
>>
>> defmodule Test do
>>   if Mix.env() == :prod do
>> defguard is_my_type(x) when true
>>   else
>> defguard is_my_type(x) when is_atom(x)
>>   end
>>
>>   def go(x) when is_my_type(x) do
>> x
>>   end
>> end
>>
>> This could be a little error prone though as unless you remember to apply
>> the guard to every clause of the function your logic may change when they
>> are removed. Even if you apply them to every clause if you use exceptions
>> as flow control you may run into problems as values that previously would
>> result in a FunctionClauseError would be passed though.
>>
>> Plenty to think about! Perhaps experiment with a little proof of concept
>> library and see what happens :)
>>
>> Cheers,
>> Louis
>>
>> On Wed, 7 Nov 2018 at 17:44 Sergiy Kukunin  wrote:
>>
> Thanks for the answers. Just want to note, that I don't want to invent
>>> type system such as in statically typed languages. I mean more about
>>> defining schemas we can check different values with. All pattern matching,
>>> guards and typespec might work for this. Furthermore, it would be cool to
>>> make it composable and reusable (such as defguards and typespecs right now).
>>>
>>> Just to conclude, I would suggest that either of these would improve the
>>> safety and convenience of the language:
>>> - allow pattern matching in custom guards (either via the built-in guard
>>> such as `Kernel.match?/2` or by extending the defguard syntax)
>>> - having a macro to check whether a value corresponds to a defined @type
>>>
>>> What's about such syntax?
>>>
>>>  defguard is_mytype({x, y}) when is_atom(x) and is_number(y)
>>>
>>>  def test({:ok, value}) when is_mytype(value), do: true
>>>  def test(_), do: false
>>>
>>>  test({:ok, {:hello, 5}}) # should be true
>>>  test({:ok, {2, 5}})  # should be false
>>>
>>> There are a couple of reasons I've raised this question:
>>>
>>> - do I miss something? don't I try to solve the problem in a wrong way?
>>> - to estimate how hard is it to implement in a 3rd-party library or does
>>> it require changes to core Elixir/ErlangVM
>>>
>>> Thanks
>>>
>>>
>>> On Wednesday, November 7, 2018 at 7:20:47 PM UTC+2, Louis Pilfold wrote:
>>>
>>>> Hi all
>>>>
>>>> The desire for more safety in Elixir is reasonable, both at compile
>>>> time and at runtime.
>>>>
>>>> The core team have previously experiment

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

[Louis Pilfold]

Hi Sergiy

The functionality you've described can be implemented with macros, no need
to modify Elixir or Erlang.

To start it could be as simple as defining guards that assert nothing in
the production environment.

defmodule Test do
  if Mix.env() == :prod do
defguard is_my_type(x) when true
  else
defguard is_my_type(x) when is_atom(x)
  end

  def go(x) when is_my_type(x) do
x
  end
end

This could be a little error prone though as unless you remember to apply
the guard to every clause of the function your logic may change when they
are removed. Even if you apply them to every clause if you use exceptions
as flow control you may run into problems as values that previously would
result in a FunctionClauseError would be passed though.

Plenty to think about! Perhaps experiment with a little proof of concept
library and see what happens :)

Cheers,
Louis

On Wed, 7 Nov 2018 at 17:44 Sergiy Kukunin  wrote:

> Thanks for the answers. Just want to note, that I don't want to invent
> type system such as in statically typed languages. I mean more about
> defining schemas we can check different values with. All pattern matching,
> guards and typespec might work for this. Furthermore, it would be cool to
> make it composable and reusable (such as defguards and typespecs right now).
>
> Just to conclude, I would suggest that either of these would improve the
> safety and convenience of the language:
> - allow pattern matching in custom guards (either via the built-in guard
> such as `Kernel.match?/2` or by extending the defguard syntax)
> - having a macro to check whether a value corresponds to a defined @type
>
> What's about such syntax?
>
>  defguard is_mytype({x, y}) when is_atom(x) and is_number(y)
>
>  def test({:ok, value}) when is_mytype(value), do: true
>  def test(_), do: false
>
>  test({:ok, {:hello, 5}}) # should be true
>  test({:ok, {2, 5}})  # should be false
>
> There are a couple of reasons I've raised this question:
>
> - do I miss something? don't I try to solve the problem in a wrong way?
> - to estimate how hard is it to implement in a 3rd-party library or does
> it require changes to core Elixir/ErlangVM
>
> Thanks
>
>
> On Wednesday, November 7, 2018 at 7:20:47 PM UTC+2, Louis Pilfold wrote:
>
>> Hi all
>>
>> The desire for more safety in Elixir is reasonable, both at compile time
>> and at runtime.
>>
>> The core team have previously experimented with introducting a compile
>> time type checking system, and we also have the dialyser and gradualizer
>> tools that can be used with Elixir.
>>
>> Checking at runtime is something we already do in Elixir and Erlang
>> through the use of pattern matching and guards such as `is_binary/1`.
>> A library of macros that automates these checks could be an interesting
>> project, perhaps an area worth exploring for members of the community.
>>
>> Cheers,
>>
> Louis
>>
>> On Wed, 7 Nov 2018, 16:46 Ivan Yurov,  wrote:
>>
> 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 Wednesday, November 7, 2018 at 12:00:53 PM UTC+1, Sergiy Kukunin
>>> wrote:
>>>>
>>>> Hello there. This is my first message to the elixir group. Thanks for
>>>> the great language.
>>>>
>>>> While I'm writing my code, I want to make functions to be safer. It's
>>>> bad practice if a function accepts unexpected input and pass it further,
>>>> and it blows in a completely different part of a system.
>>>>
>>>> At first glance, I have pattern matching, but it's pretty limited. It
>>>> becomes really powerful in conjunction with guards, so I can write a
>>>> signature to match literally everything.
>>>> But they hard to re-use, If I have multiple functions operating with
>>>> the same object. Yes, I can define a custom guard, but can I use pattern
>>>> matching there? `Kernel.match?/2` doesn't work, so I'm limited with only
>>>> guards in my custom guards.
>>>>
>>>> Another thing that we have typespecs. It seems exactly what I'm looking
>>>> for: you have a wide set of built-in types, and I can easily compose and
>>>> reuse my own types. The problem with it, that it doesn't affect runtime. I
>>>> know about static analyzer `dialyzer`, but I'm not sure it will catch all
>>>> cases since it's a stati

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

[Louis Pilfold]

Hi all

The desire for more safety in Elixir is reasonable, both at compile time
and at runtime.

The core team have previously experimented with introducting a compile time
type checking system, and we also have the dialyser and gradualizer tools
that can be used with Elixir.

Checking at runtime is something we already do in Elixir and Erlang through
the use of pattern matching and guards such as `is_binary/1`.
A library of macros that automates these checks could be an interesting
project, perhaps an area worth exploring for members of the community.

Cheers,
Louis

On Wed, 7 Nov 2018, 16:46 Ivan Yurov,  wrote:

> 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 Wednesday, November 7, 2018 at 12:00:53 PM UTC+1, Sergiy Kukunin wrote:
>>
>> Hello there. This is my first message to the elixir group. Thanks for the
>> great language.
>>
>> While I'm writing my code, I want to make functions to be safer. It's bad
>> practice if a function accepts unexpected input and pass it further, and it
>> blows in a completely different part of a system.
>>
>> At first glance, I have pattern matching, but it's pretty limited. It
>> becomes really powerful in conjunction with guards, so I can write a
>> signature to match literally everything.
>> But they hard to re-use, If I have multiple functions operating with the
>> same object. Yes, I can define a custom guard, but can I use pattern
>> matching there? `Kernel.match?/2` doesn't work, so I'm limited with only
>> guards in my custom guards.
>>
>> Another thing that we have typespecs. It seems exactly what I'm looking
>> for: you have a wide set of built-in types, and I can easily compose and
>> reuse my own types. The problem with it, that it doesn't affect runtime. I
>> know about static analyzer `dialyzer`, but I'm not sure it will catch all
>> cases since it's a static check, not a runtime.
>>
>> Let's assume a simple function, that wraps a value into a list:
>>
>>   @spec same(number()) :: [number()]
>>   def same(number) do
>> [number]
>>   end
>>
>> I'm sure the `dialyzer` won't complain since a signature is valid. But
>> what if I do: `same("abc")` ? What will prevent Elixir from returning a
>> wrong type? I guess, nothing.
>> An example from a real life: I have a function, that accepts a custom
>> shaped value (using tuples) and feeds it to a queue. Then, in the totally
>> different part of the system, a consumer gets values from the queue. And
>> when a wrong value was fed on the producer side, it blows on the consumer
>> side. So I decided to put some constraints on the producer side to fail
>> fast.
>>
>> Yes, I could define a guard, but again, if I have a pretty complex type
>> instead of the simple `number`, I had to duplicate the type defining: one
>> for typespec, another is for a custom guard (which is limited, since I
>> can't use pattern matching there).
>>
>> Wouldn't it be cool, If we had a mechanism to assert a value to its type,
>> in runtime? To avoid performance penalty we could enable it only for
>> runtime. Is there a way right now to check whether a value corresponds to a
>> type in runtime? Can I implement a custom macro to provide a good DSL for
>> this? Is it helpful at all?
>>
>> P.S. You may say, use structs and pattern matching would work in this
>> case. But what if my type is better represented by a tuple: {atom(),
>> pos_integer(), string()}. Converting it to a struct might complicate a way
>> to work with the value.
>>
> --
> 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/8c4d9dac-134d-471c-a402-e9696bf5aecf%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/CABu8xFAJxLReOB%2Bb97ADx%3Du8Ax1Ho2AcurMnmJLwmoNit8FSnA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:8357] [Proposal] Add function Kernel.delete_in/2

[Louis Pilfold]

Hey

How would it know how to delete a value from the given data structure? The
Access protocol could be implemented for any term.

Cheers,
Louis

On Sat, 27 Oct 2018, 18:51 Jonathan Arnett,  wrote:

> It would be useful to have a function that uses the Access protocol to
> delete elements within nested data structures. This is similar in concept
> to Kernel.pop_in/2 , but
> Kernel.delete_in/2 should just return the data structure without the
> specified element, whereas Kernel.pop_in/2 returns a tuple whose first
> element is the removed value and second element is the data structure
> without the specified element. The return structure of
> Kernel.delete_in/2 would allow it to be more easily chained than
> Kernel.pop_in/2.
>
> Expected behavior
> Kernel.delete_in(%{foo: "bar", baz: "qux"}, [:foo])
> #=> %{baz: "qux"}
>
> Kernel.delete_in(%{foo: %{bar: "baz", qux: "quux"}}, [:foo, :qux])
> #=> %{foo: %{bar: "baz"}}
>
>
> --
> 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/85369f10-5234-4c75-a282-cd644e380a0b%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/CABu8xFAJNsR4p0PHSLqn%3D5Y%2Bwj9v7uBD%2BeZzetxUAKErpXW-EQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:8323] [Proposal] Allow guards to be interspersed anywhere in clause heads

[Louis Pilfold]

Hey

> is there a good reason *not* to expand the expressivity of guard clauses
in the core of the language beyond that which erlang offers?

I've no strong opinion on the proposal, but I'd just like to point out
that expressivity
has a formal CS definition and implementing this proposal will not increase
the expressive power of guard clauses as they will not be capable of any
functionality they did not have before.

This is a matter of style and syntax.

Cheers,
Louis

On Mon, 24 Sep 2018 at 21:13 Christopher Keele 
wrote:

>  > *If the goal were primarily macro usage, wouldn't this type of thing
> already be possible with a macro today?*
>
> > *Macros are more than capable of providing this functionality, you'd
> just need to define your own `def` like macro that generates the desired
> function.*
>
> This is absolutely true, and expat does something similar today. It could
> be done easier and better in core, of course. I think the heart of the
> proposal is: given that this is straightforwardly possible today, and the
> implementation identical and completely deterministic no matter the
> application, is there a good reason *not* to expand the expressivity of
> guard clauses in the core of the language beyond that which erlang offers?
>
> The macro-authors-over-common-coding argument is me simply saying, let's
> consider this from the perspective of increasing the language's
> extensibility first, since I suspect the discussion around whether or not
> it makes day-to-day coding more productive to be far more opinion-oriented.
>
> I am not sold on the idea myself, which is why I dug into the
> implementation a bit so I could present it better. It absolutely could be
> done via macro, but I think it exists at an interesting low-hanging fruit,
> low-risk way to make the language itself more powerful today.
>
> > *IIRC, macros do not allow to abstract both the pattern match and the
> guard within the same expression.*
>
> You do a better job of summarizing how this could be used in core today
> than I did. I am not sure how common the use-case is either, but I do have
> one concrete example in expat and I wonder what might embraced in the
> future if this purely historical grammatical restriction were lifted.
>
> --
> 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/9e9be43d-b772-480c-afe9-bb07a7e01119%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/CABu8xFDw%2B30jQ%2BhfsLS7OxXSFf3gT7XSxBZr-qGuBC6_kY-Tww%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:8321] [Proposal] Allow guards to be interspersed anywhere in clause heads

[Louis Pilfold]

Hey

Macros are more than capable of providing this functionality, you'd just
need to define your own `def` like macro that generates the desired
function.

```
MyLib.def my_fun(my_var when my_var in [:foo, :bar])
```

Cheers,
Louis

On Mon, 24 Sep 2018 at 20:01 Fernando Tapia Rico 
wrote:

> IIRC, macros do not allow to abstract both the pattern match and the guard
> within the same expression. For example, the Elixir codebase contains a
> helper function that abstracts the pattern match, the guard and the "read"
> function for dates and times separately. Here is the helper function
> https://github.com/elixir-lang/elixir/blob/master/lib/elixir/lib/calendar/iso.ex#L39-L70;
> and here is an example of its usage
> https://github.com/elixir-lang/elixir/blob/master/lib/elixir/lib/calendar/datetime.ex#L522-L531
> .
>
> Besides, as described by José Valim in here
> ,
> internal guards would allow to write macros like:
>
> def my_fun(my_macro())
>
> which would be expanded to:
>
> def my_fun(my_var when my_var in [:foo, :bar])
>
> and rewritten by the Elixir compiler to:
>
> def my_fun(my_var) when my_var in [:foo, :bar]
>
> However, I'm not sure how common are those use cases 樂.
>
> On Monday, September 24, 2018 at 8:22:07 PM UTC+2, Allen Madsen wrote:
>
>> If the goal were primarily macro usage, wouldn't this type of thing
>> already be possible with a macro today?
>>
>> Allen Madsen
>> http://www.allenmadsen.com
>>
>>
>> On Mon, Sep 24, 2018 at 11:34 AM Christopher Keele 
>> wrote:
>>
> That's a good point. I suspect the convention around manual usage would
>>> converge around:
>>>
>>> *def foo(%{x: x} = result when x > 1), do: 1*
>>>
>>> which parses as expected. This version feels more natural to me.
>>>
>>> I don't think the other form would accidentally be introduced while
>>> injecting one snippet of AST, because the tree would never be constructed
>>> the wrong way. String-based expression interpolation might make that
>>> mistake, but if you're metaprogramming with literal strings of code you've
>>> already made a mistake.
>>>
>>> I hadn't typed out an assignment case with inline guards, it does feel
>>> like it's doing too much in a short space with few grammar tokens to help
>>> understand it. That's a good argument for intentionally discouraging these
>>> constructs outside of metaprogramming, rather than adopting it as a common
>>> usage language feature.
>>>
>>> --
>>> 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/f2fafacb-3302-4c03-9b1b-ed766a896cc2%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/7fda093f-03b5-4d1d-9c16-73c9475ca6a7%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/CABu8xFA4Eh_zuzbR2ykUzC7UXC%3DcK7NmuyLrXjH%3DgkFe8%2BJzYg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:8301] Proposal: Comments in AST

[Louis Pilfold]

Hey

I'm a little out of touch with this area, but isn't this what we previously
did? I remember comments being stored in meta during the creation of the
formatter. Or did I make that up?

Cheers,
Louis

On Mon, 17 Sep 2018 at 19:17 José Valim 
wrote:

> I like the metadata idea a lot, thanks. We still need someone to send a
> detailed proposal, including what will happen with inline comments,
> comments inside blocks and comments as the last line of a block with no
> expression afterwards.
>
> We also need a discussion on what will happen with nodes that do not have
> a metadata entry. Wrapping those in a block is likely enough (but it will
> break semantics, for example, in keywords lists). So it would need to be an
> opt-in feature only.
>
> Once all the details are ironed out, then somebody can go ahead and fully
> implement it. :)
> --
>
>
> *José Valim*
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Director of R
>
> --
> 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/CAGnRm4J4%2BcTqcXH_ESJL2_o7rv5OJxkf_yJDpVAH%3DCjH2mmO7w%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/CABu8xFAk6UQJbbMcD2xkwJFLPM%3DbASSnOqL6ihSdUQEMpuKNGg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:8293] Proposal: Comments in AST

[Louis Pilfold]

Hi Steve

The formatter extracts comments from Elixir source like so:
https://github.com/elixir-lang/elixir/blob/9cf118bd123deb945be71bf3ea2b48cd271088f0/lib/elixir/lib/code/formatter.ex#L199-L225

This may help you.

Cheers,
Louis

On Sun, 16 Sep 2018 at 17:59 Steve Morin  wrote:

> Wanted to see what peoples thoughts are about adding comments to the AST.
>
> One use-case is to be able to parse and manipulate Source files outside of
> just macros but in that case you would want to be able to preserve
> comments.
>
> E.g. Read a source file, manipulate it, write that source file back to a
> file.
>
> This would allow people/tooling to use elixir to parse and manipulate
> source files.
>
> If this might disturb existing consumers of the AST maybe this could be
> added as a option to existing Macro functions so that I could be turned on
> for people with this use-case.
>
> --
> 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/955237D8-31DE-448C-9777-1104F1175DC7%40gmail.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/CABu8xFCqNwQWGjr7PmeGgNOsKBcbFfQHoKLXmZuHahSv_vTxtA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:8269] [Proposal] Mix format multiline pipelines

[Louis Pilfold]

Hi

The formatter will do this when either the pipeline is too long to fit in
one line, or if there is at least one newline in the pipeline.

Cheers,
Louis


On Sun, 2 Sep 2018, 20:39 Sofiane Baddag,  wrote:

> It would be nice to have multiline pipelines formatted automatically with
> Mix.
>
> With the current format (no changes):
>
> def hello(arg) do
> arg |> func1 |> func2 |> func3
> end
>
>
> Expected behaviour:
>
> def hello(arg) do
> arg
> |> func1
> |> func2
>  |> func3
> end
>
> --
> 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/bdd16648-3bf4-4a9b-a258-aaa0a21bc20d%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/CABu8xFD%3D6T7JMwFw_6-5Fxqdj3PSrYVWG2%3DQ5hzc0iP6LzYmvQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:8034] Re: Module inheritance

[Louis Pilfold]

Hey

I'd say the disadvantage is that it'd be making Elixir a bigger and more
complex language. I think there's value in having a small core language
that gives users the tools to extend it as required.

And there's always the question what exactly should be a core feature. I
don't use any languages that support inheritance, and thus to be this seems
like an exotic niche feature rather than a core language feature. :)

Cheers,
Louis

On Mon, 28 May 2018, 00:11 Steve Morin, <steve.mo...@gmail.com> wrote:

> Re:my prior comments, think it would be good as a add on package for those
> that want to use that.
>
> On May 27, 2018, at 16:00, 'boris kotov' via elixir-lang-core <
> elixir-lang-core@googlegroups.com> wrote:
>
> Hi Louis,
>
> yeah you are right, its something that I am already thinking about.
> I was just wondering, what are the cons of putting it directly into the
> language, as it seems to me, to be a core-language-feature.
>
> Cheers,
> Boris
>
> Am Montag, 28. Mai 2018 00:44:31 UTC+2 schrieb Louis Pilfold:
>>
>> Hi Boris
>>
>> Regardless of whether this functionality is desirable, one could
>> implement functionality like this using Elixir's macro system. As such
>> there is no need for it to be a core language feature.
>>
>> If you want it why not implement it and release it as a Hex package? That
>> way you get the feature you want, and of it proves to be useful others can
>> also make use of it too.
>>
>> Cheers,
>> Louis
>>
>> On Sun, 27 May 2018, 23:20 'boris kotov' via elixir-lang-core, <
>> elixir-l...@googlegroups.com> wrote:
>>
>>> No, I meant this as a language feature, for users, to re-use
>>> functionalities from other modules by extending them.
>>> For sure, if you are going to extend something, you should know what the
>>> origin is doing, and why you are extending it.
>>> I am thinking about some community packages, where some of your special
>>> use-cases are not covered, and you would like to "extend" it, not fully
>>> reimplement it.
>>> The same goes for already existing erlang packages, where you want to
>>> touch some parts and let the rest do its job.
>>> IMHO "use" is actually meant for this kind of extension, but its very
>>> strict and limited by the actual implementation, which is good actually.
>>> Extend on the other hand would be more flexible, which also a good thing
>>> :)
>>>
>>> Documentation, I see, might be a problem, if you want to publish it. I
>>> am not sure, but I think it should be possible to take the current
>>> documentation from the origin on the fly while compiling, maybe I am wrong.
>>>
>>> Am Sonntag, 27. Mai 2018 23:23:44 UTC+2 schrieb José Valim:
>>>
>>>> Hi Boris,
>>>>
>>>> Simply because it is a pattern we don't want to encourage, as it fully
>>>> couples a module to another one.
>>>>
>>>> And there are questions such as documentation. Are you going to
>>>> document the delegated functions? If not, why not? Should we copy the
>>>> delegations? Then the examples are likely outdated.
>>>>
>>>> If you feel like you need to delegate a whole module, it is better to
>>>> re-evaluate the solution and discuss the problem, as it is very unlikely in
>>>> Elixir.
>>>>
>>>
>>>>
>>>>
>>>> *José Valim*
>>>> www.plataformatec.com.br
>>>> Skype: jv.ptec
>>>> Founder and Director of R
>>>>
>>>> On Sun, May 27, 2018 at 11:14 PM, 'boris kotov' via elixir-lang-core <
>>>> elixir-l...@googlegroups.com> wrote:
>>>>
>>> Hey José,
>>>>>
>>>>> I am the guy, who just asked about defdelegate (n-ary) (if you still
>>>>> can remember)
>>>>> And what I was actually looking for is `extends SomeModule` feature,
>>>>> instead of delegating all functions one-by-one * arity.
>>>>>
>>>>> Just wondering, why this feature is still not in the core :) ?
>>>>>
>>>>> Thanks,
>>>>> Boris
>>>>>
>>>>>
>>>>> Am Freitag, 1. Februar 2013 22:57:12 UTC+1 schrieb José Valim:
>>>>>>
>>>>>> The current behaviour is correct. Ideally we would have "excluding
>>>>>> end" ranges, but we don't. I have updated the gist to consider zero arity
>>>>>> 

Re: [elixir-core:8030] Re: Module inheritance

[Louis Pilfold]

Hi Boris

Regardless of whether this functionality is desirable, one could implement
functionality like this using Elixir's macro system. As such there is no
need for it to be a core language feature.

If you want it why not implement it and release it as a Hex package? That
way you get the feature you want, and of it proves to be useful others can
also make use of it too.

Cheers,
Louis

On Sun, 27 May 2018, 23:20 'boris kotov' via elixir-lang-core, <
elixir-lang-core@googlegroups.com> wrote:

> No, I meant this as a language feature, for users, to re-use
> functionalities from other modules by extending them.
> For sure, if you are going to extend something, you should know what the
> origin is doing, and why you are extending it.
> I am thinking about some community packages, where some of your special
> use-cases are not covered, and you would like to "extend" it, not fully
> reimplement it.
> The same goes for already existing erlang packages, where you want to
> touch some parts and let the rest do its job.
> IMHO "use" is actually meant for this kind of extension, but its very
> strict and limited by the actual implementation, which is good actually.
> Extend on the other hand would be more flexible, which also a good thing :)
>
> Documentation, I see, might be a problem, if you want to publish it. I am
> not sure, but I think it should be possible to take the current
> documentation from the origin on the fly while compiling, maybe I am wrong.
>
> Am Sonntag, 27. Mai 2018 23:23:44 UTC+2 schrieb José Valim:
>
>> Hi Boris,
>>
>> Simply because it is a pattern we don't want to encourage, as it fully
>> couples a module to another one.
>>
>> And there are questions such as documentation. Are you going to document
>> the delegated functions? If not, why not? Should we copy the delegations?
>> Then the examples are likely outdated.
>>
>> If you feel like you need to delegate a whole module, it is better to
>> re-evaluate the solution and discuss the problem, as it is very unlikely in
>> Elixir.
>>
>
>>
>>
>> *José Valim*
>> www.plataformatec.com.br
>> Skype: jv.ptec
>> Founder and Director of R
>>
>> On Sun, May 27, 2018 at 11:14 PM, 'boris kotov' via elixir-lang-core <
>> elixir-l...@googlegroups.com> wrote:
>>
> Hey José,
>>>
>>> I am the guy, who just asked about defdelegate (n-ary) (if you still can
>>> remember)
>>> And what I was actually looking for is `extends SomeModule` feature,
>>> instead of delegating all functions one-by-one * arity.
>>>
>>> Just wondering, why this feature is still not in the core :) ?
>>>
>>> Thanks,
>>> Boris
>>>
>>>
>>> Am Freitag, 1. Februar 2013 22:57:12 UTC+1 schrieb José Valim:

 The current behaviour is correct. Ideally we would have "excluding end"
 ranges, but we don't. I have updated the gist to consider zero arity
 functions:

 https://gist.github.com/ff41078606cfe0e55eaf


 *José Valim*
 www.plataformatec.com.br
 Skype: jv.ptec
 Founder and Lead Developer


 On Fri, Feb 1, 2013 at 11:10 AM, Yurii Rashkovskii 
 wrote:

> It is. It was the other way around some time ago
> On Feb 1, 2013 10:09 AM, "Oren Ben-Kiki"  wrote:
>
>> A correction: 1..arity doesn't work when arity is 0 (it actually
>> generates [1,0] instead of []). Is this the expected behavior?
>>
>>
>> On Mon, Jan 28, 2013 at 11:29 PM, Oren Ben-Kiki 
>> wrote:
>>
>>> I agree this should be used very sparingly; in my case, there's a
>>> single specific case I want to use it for in my system. That said, it is
>>> much cleaner to do it the way you provided - thanks!
>>>
>>>
>>> On Monday, January 28, 2013 11:19:54 PM UTC+2, José Valim wrote:

 I don't particularly encourage extends but it can be easily
 achieved as:

 https://gist.github.com/ff41078606cfe0e55eaf

 *José Valim*
 www.plataformatec.com.br
 Skype: jv.ptec
 Founder and Lead Developer

>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "elixir-lang-core" group.
>>> To unsubscribe from this group, send email to
>>> elixir-lang-co...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>>
>> --
>> 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.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
> --
> 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 

Re: [elixir-core:7994] [Proposal] Crypto module wrapper

[Louis Pilfold]

Hiya

If Erlang crypo module could be improved or superseded I'd like for those
improvements implemented in Erlang so all languages on the BEAM can make
use of them, rather than just Elixir.

Cheers,
Louis

On Mon, 14 May 2018, 00:09 Griffin Byatt,  wrote:

> I know the “wrap the Erlang module” proposals are not particularly
> popular,  and the general consensus is, “make it into a library if you want
> it”. However, I think in this case it would be a useful addition to the
> Elixir language. Here is my reasoning:
>
> The Erlang crypto module is not particularly user-friendly, and the
> supported ciphers are foot-guns with potentially severe failure modes.
> There are a number of libraries that attempt to address this issue, but
> they are largely insufficient for general use — i.e offering ECB mode,
> unauthenticated CBC, static secrets/IVs, non-constant-time comparisons,
> etc. Considering the importance of the subject (and the ease of misuse), I
> think a *somewhat* opinionated wrapper could save a lot of heartache.
>
> Here are some initial ideas:
>
> * `Crypto.equals(string1, string2)`  for constant-time comparisons.
> * `Crypto.encrypt(message, secret)` for a default authenticated encryption
> - this could also be future-proofed to allow for better ciphers with
> something like `Crypto.auth_encrypt_cbc(message, secret)`.
> * `Crypto.decrypt(ciphertext, secret)` for decryption.
> * `Crypto.sign(message, secret)` for a default symmetric signature. Same
> as encryption - for example, `Crypto.sign_sha256` or something like that.
> * `Crypto.verify(signed, secret)` for verification.
>
> Basically, only offer semi-opinionated wrapper functions that will be
> closer to default-secure. Like, if you want md5, or ECB, you can go to the
> Erlang module, but this way more people will start with the secure choices.
>
> Would love to hear thoughts on this. Thanks!
>
> --
> 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/e2592402-3095-40c4-862d-a58d273d4420%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/CABu8xFB3OL1YbPsHykkfZN44f5ZVm70gww4V-_nHeLo5VNgRew%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:7974] Proposal/Enhance for Elixir Formatter: Format Options (for Numbers)

[Louis Pilfold]

I'd like to offer a counter point in that I think the lack of configuration
is one of the best things about the formatter as it stands.

Without configuration they're is only one style, and this the is no
opportunity for teams to squabble about code style/linter format. It also
means that (hopefully) all the Elixir code out the works look (relatively)
similar.

I don't think the advantage offered by any specific configuration is worth
sacrificing this feature.

I gave a talk at last year's Elixir London on the subject
https://youtu.be/g4HXeP_CZbc

Cheers,
Louis

On Sat, 21 Apr 2018, 09:06 Allen Wyma,  wrote:

> First of all, I'd like to say thanks so much for the elixir formatter. I
> do like nearly all of the defaults. There's one place that I would like to
> change:
>
> formatting of numbers.
>
> I'd like to be able to turn off the auto formatting of numbers to add in
> underscores after every third number.
>
> Reason:
> I do have some test data in my elixir files that I use to check
> information and when I search for certain test data by ID, which is a long
> number, it won't be found cause of the underscores added to the number.
>
> I can see this being useful if you're working with currency, or numbers
> with some meaning of counting; it does make the numbers easier to read, but
> if you're reading like an ID, then it becomes a big difficult to understand.
>
> %{ "specialId" => 10002 } # => %{ "specialId" => 100_000_002 }
>
> --
> 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/6f055bb9-3c2d-4d65-9cf4-8904509844b8%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/CABu8xFA3q4hCit8jk0eyDZXL1xube%2BfAMy4avWPtikU2cnT-ZQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:7967] Re: Pipe and anonymous functions

[Louis Pilfold]

It's not that weird when you think about it in terms of the AST that the
macro operates on, and not in terms of types.

The former would require rewriting the forms into anon function calls,
while the latter just prepends a value onto the argument list. `|>` is a
very very simple macro that can be implemented in a single line. There's a
bunch of friendly error handling in the one in Kernel, but it's still just
as simple.

Cheers,
Louis

On Wed, 18 Apr 2018 at 11:36 Dylan Johnston 
wrote:

> Sorry to dredge up an old thread but I wanted to push back against this
>> again. The point of the pipe operator is to be able to clearly express the
>> flow of data through a transformation. Claiming the pipe operator shouldn't
>> be able to handle captured or anonymous functions because it confuses how
>> it works is confusing an implementation detail of how the pipe operator
>> macro works now to how it is semantically expected to behave. Having to
>> wrap them in parenthesis and an invocation introduces a great deal of noise
>> to what could be an extremely simple syntax. As Wojtek Mach showed, it's
>> fairly easy to get the pipe operator to handle these cases, especially
>> since you're pattern matching against them anyway to give error messages.
>> Why pattern match only to give an error when it's easy and straightforward
>> to just make it work, what else could a user intend other than to call the
>> function?. There's a pull request here I made than extends his work so that
>> captured functions and anonymous functions both work.
>> https://github.com/wojtekmach/pipe_capture/pull/1
>>
>
> "Hello"
> |> fn x -> IO.puts x end
> |> /1
> |> (:stderr, &1)
>
>  vs
>
> "Hello"
> |> (fn x -> IO.puts x; x end).()
> |> (/1).()
> |> ((:stderr, &1)).()
>
> It seems weird to me that the pipe macro works exclusively on already
> invoked functions and doesn't know what to do with a function reference.
>
> --
> 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/b2182e21-939e-4762-b603-9cd492e1650b%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/CABu8xFDB7oMcaXNfrYbkh%3DrLz7YcZMRzcuODjHWaJKp5DkNxZw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:7931] Coverage by default

[Louis Pilfold]

I would imagine it would be the same, but using the already included cover
tool rather than the ExCoveralls tool. That way there is no need for the
core team to adopt and maintain ExCoveralls and this new UI can be used by
other BEAM languages as well.

Cheers,
Louis

On Sat, 3 Mar 2018, 23:36 Yordis Prieto,  wrote:

> Jose,
>
> I would like to try to do something if you defines what you are looking
> for (specially from front end code perspective).
>
> What is missing from
> https://github.com/parroty/excoveralls#mix-coverallshtml-show-coverage-as-html-report
> ?
>
>
>
>
> On Tuesday, February 20, 2018 at 7:31:32 AM UTC-8, José Valim wrote:
>
>> Talking about excoveralls, ExUnit already ships with coverage support out
>> of the box via Erlang/OTP's cover .
>>
>> All of the mechanisms to collect metrics that excoveralls uses comes from
>> cover and it would be fantastic if someone contributed excoveralls-like
>> HTML pages back to OTP, with overview and navigation sidebar.
>>
>> If somebody would like to do this but has trouble with getting started
>> with the Erlang/OTP repository, please let me know and I will be glad to
>> help.
>>
>
>>
>> *José Valimwww.plataformatec.com.br
>> Founder and Director of R*
>>
>> On Sat, Feb 17, 2018 at 12:41 PM, Yordis Prieto 
>> wrote:
>>
> I found myself adding excoveralls in every single project that I do.
>>>
>>> Wouldn't be better to add such of tooling by default with the testing
>>> tools?
>>>
>>>
>>>
>>>
>>> P.S: even ex_doc is the same situation, every project I add the deps.
>>>
>> --
>>> 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/af2aaee3-fbe8-4838-a53f-17a9eca8318e%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/52357b35-2a0b-463e-b39c-8f5f1e2688b0%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/CABu8xFDFeP-exsHn32gAosx6oX%3DO4Z5uMRexf7ym8LnNkhEEcw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:7926] Proposal: Addition of `either` and `both` operators

[Louis Pilfold]

Hi

What would this add to the language that we don't already have? It seems to
overlap with &&, ||, and, or, Enum.any, and Enum.all. I would rather we
have fewer ways in the standard library to write the same thing, rather
than more, so new people coming to this language have less special cases,
syntaxes and rules to learn.

This could be implemented today as a macro quite easily. Perhaps make a hex
package for this as then people can use this if they wish and we don't have
to modify the standard library and wait for another Elixir released.

Cheers,
Louis

On Fri, 2 Mar 2018, 05:55 Daniel Angell,  wrote:

> As an alternative to:
>
> if foo(my_baz) and bar(my_baz) do
>   # ...
> end
>
> it would be great to have `either` and `both` operators as sugar
>
> if my_baz both foo and bar do
>   # ...
> end
>
> if my_baz either foo or bar do
>   # ...
> end
>
> These operators could be equivalent to the following function definitions
>
> def both(_, true, true),  do: true
> def both(_, false, _),do: false
> def both(_, _, false),do: false
> def both(value, true, right), do: right.(value)
> def both(value, left, true),  do: left.(value)
> def both(value, left, right) do
>   left.(value) and right.(value)
> end
>
> def either(_, true, _),  do: true
> def either(_, _, true),  do: true
> def either(_, false, false), do: false
> def either(value, left, false),  do: left.(value)
> def either(value, false, right), do: right.(value)
> def either(value, left, right) do
>   left.(value) or right.(value)
> end
>
> However, the support for boolean operands might not end up being the most
> readable.
>
> --
> 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/0bae2cc5-a466-4f70-b069-878f594d45ef%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/CABu8xFBpm5TfM59g9%3Db62fVs3%3DTTcXrakXDiAbfUxTrtRm%3D%2BRw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:7914] Introduce Sum Types

[Louis Pilfold]

That would be the library I started writing that I was looking for an
alternative to finishing :D

Guess I should finish it!

On Mon, 26 Feb 2018, 22:02 OvermindDL1, <overmind...@gmail.com> wrote:

> So something more like https://github.com/lpil/sum or so (undocumented,
> but it looks right, it's the first thing I found via a github search).
>
> There is one specific one I'm thinking of but can't for the life of me
> remember it's name...  I wish hex.pm had the ability to search module and
> function names in a libraries public API...  >.>
>
> Either way, it's not hard to write a library to support it though.  :-)
>
>
> On Sunday, February 25, 2018 at 9:58:44 AM UTC-7, Louis Pop wrote:
>
>> If I recall correctly this library wraps the values and does not offer
>> compile time checks, which is the inverse of what I'm after.
>>
>> I want unwrapped values and compile time checks :)
>>
>> Cheers,
>> Louis
>>
>> On Sun, 25 Feb 2018, 16:00 OvermindDL1, <overm...@gmail.com> wrote:
>>
> There are at least 2 others that I know of, and I can find those for you
>>> too tomorrow if you want them, they have different features and focuses,
>>> but the one that immediately comes to mind is:
>>> https://github.com/expede/algae
>>>
>>> Expede on GitHub has a lot of cool and useful little 'core' elixir
>>> libraries in my opinion.
>>>
>>> On Feb 24, 2018 06:46, "Louis Pilfold" <louisp...@gmail.com> wrote:
>>>
>> Hi
>>>>
>>>> I started to implement such a library, but I would much prefer to use
>>>> an existing one. I was unable to find any, wild you be able to share some
>>>> links?
>>>>
>>>> Thanks,
>>>> Louis
>>>>
>>>> On Fri, 23 Feb 2018, 18:09 OvermindDL1, <overm...@gmail.com> wrote:
>>>>
>>> There are some library that add sum types to Elixir that do 'some'
>>>>> compile-time checks (like case's and so forth).  It would be useful built
>>>>> in to elixir (though not any of the current library implementations) but
>>>>> the libraries already do support much of it.
>>>>>
>>>>>
>>>>> On Friday, February 16, 2018 at 6:35:03 AM UTC-7, Ben Wilson wrote:
>>>>>>
>>>>>> 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 16, 2018 at 6:38:07 AM UTC-5,
>>>>>> maen...@joshmartin.ch wrote:
>>>>>>>
>>>>>>> Hey Louis,
>>>>>>>
>>>>>>> I think it should include compile time checks. Mostly I would expect
>>>>>>> those for function headers, case blocks and with blocks.
>>>>>>>
>>>>>>> Dialyzer already checks many of those conditions, but I would like
>>>>>>> to go a step further.
>>>>>>> Your mentioned library looks really interesting. Making it work
>>>>>>> together with existing type specifications would be really cool.
>>>>>>>
>>>>>>> With for example structs, I can achieve safety really easy by adding 
>>>>>>> *%Struct{}
>>>>>>> = my_input* to the function header.
>>>>>>>
>>>>>>> I would like to have a mechanism that works similarly, but
>>>>>>> additionally checks uncovered types of a sum. (If you would for example 
>>>>>>> not
>>>>>>> cover the None of a Maybe)
>>>>>>>
>>>>>>> I think that this could tremendously improve the code quality.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Jony
>>>>>>>
>>>>>>> Am Freitag, 16. Februar 2018 11:57:00 UTC+1 schrieb Louis Pilfold:
>>>>>>>>
>>>>>>>> Hey Jony
>>>>>>>>
>>>>>>>> Would this involve some form of compile time type checking for
>>>>>>>> these values? If not we already have them in the form of tuples.
>>>>>>>>

Re: [elixir-core:7910] Enhancement request: parse character offsets for AST node

[Louis Pilfold]

Hi there

Given we have the formatter now I would be tempted to avoid editing strings
and instead update the AST of the file, render that to a string, format it
and write it back to the file. Would be more reliable.

Cheers,
Louis

On Mon, 26 Feb 2018, 12:11 Serge Smetana,  wrote:

> Hi,
>
> I would like Elixir AST nodes to include begin and end parse character
> offsets.
> This would make it easier to write refactoring tools that modify parts of
> Elixir source files.
>
> Usecase:
>
> We have a library https://github.com/assert-value/assert_value_elixir
> that is
> able to create and update expected values in tests. For example, given the
> following:
>
> assert_value 2 + 2 == 2 + 3
>
> our code will find the location of `2 + 3` and replace it with `4`:
>
> assert_value 2 + 2 == 4
>
> Today determining the location of `2 + 3` in the source file is
> difficult.  For
> now, we use a custom-made parser which processes code char by char until
> it gets
> value matching AST:
>
> https://github.com/assert-value/assert_value_elixir/blob/master/lib/assert_value/parser.ex
> But if we had the parse offsets it would be much easier.
>
> Proposed interface:
>
> Probably need two sets of offsets, exclusive and inclusive of children.
> For
> each probably best to store beginning offset and length. Will need
> reasonable
> handling for parentheses and other tokens that do not make it into AST.
>
> Existing implementation:
>
> Elixir AST nodes do have useful info on this already. We use the "line:"
> which
> is very helpful. We don't use "column:", it did not seem useful given our
> implementation.  We may be missing something obvious here.
>
> Details:
>
> In Elixir 1.6 compiled code AST has only function line number in meta. Even
> "columns: true" in Code.string_to_quoted gives only function starting
> column
> without information about arguments.
>
> Consider the following code:
>
> Code.string_to_quoted!("(41.00 == 42.)", columns: true)
> #=> {:==, [line: 1, column: 8], [41.0, 42.0]}
>
> From the AST you don't know where to find 41.00 and 42. in a code.
> Column information does not help. AST values of 41.0 and 42.0 don't have
> information about how original values were formatted.
>
> Thanks,
> Serge
>
> --
> 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/4dbc37cc-6630-4989-acc0-c4acfd719a5b%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/CABu8xFDcupN2SX%2Bivg%2BTJ7Q0LGbxARjAgRz-uta2ck8L%3DaTmKg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:7900] Introduce Sum Types

[Louis Pilfold]

If I recall correctly this library wraps the values and does not offer
compile time checks, which is the inverse of what I'm after.

I want unwrapped values and compile time checks :)

Cheers,
Louis

On Sun, 25 Feb 2018, 16:00 OvermindDL1, <overmind...@gmail.com> wrote:

> There are at least 2 others that I know of, and I can find those for you
> too tomorrow if you want them, they have different features and focuses,
> but the one that immediately comes to mind is:
> https://github.com/expede/algae
>
> Expede on GitHub has a lot of cool and useful little 'core' elixir
> libraries in my opinion.
>
> On Feb 24, 2018 06:46, "Louis Pilfold" <louispopin...@gmail.com> wrote:
>
>> Hi
>>
>> I started to implement such a library, but I would much prefer to use an
>> existing one. I was unable to find any, wild you be able to share some
>> links?
>>
>> Thanks,
>> Louis
>>
>> On Fri, 23 Feb 2018, 18:09 OvermindDL1, <overmind...@gmail.com> wrote:
>>
>>> There are some library that add sum types to Elixir that do 'some'
>>> compile-time checks (like case's and so forth).  It would be useful built
>>> in to elixir (though not any of the current library implementations) but
>>> the libraries already do support much of it.
>>>
>>>
>>> On Friday, February 16, 2018 at 6:35:03 AM UTC-7, Ben Wilson wrote:
>>>>
>>>> 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 16, 2018 at 6:38:07 AM UTC-5, maen...@joshmartin.ch
>>>> wrote:
>>>>>
>>>>> Hey Louis,
>>>>>
>>>>> I think it should include compile time checks. Mostly I would expect
>>>>> those for function headers, case blocks and with blocks.
>>>>>
>>>>> Dialyzer already checks many of those conditions, but I would like to
>>>>> go a step further.
>>>>> Your mentioned library looks really interesting. Making it work
>>>>> together with existing type specifications would be really cool.
>>>>>
>>>>> With for example structs, I can achieve safety really easy by adding 
>>>>> *%Struct{}
>>>>> = my_input* to the function header.
>>>>>
>>>>> I would like to have a mechanism that works similarly, but
>>>>> additionally checks uncovered types of a sum. (If you would for example 
>>>>> not
>>>>> cover the None of a Maybe)
>>>>>
>>>>> I think that this could tremendously improve the code quality.
>>>>>
>>>>> Cheers,
>>>>> Jony
>>>>>
>>>>> Am Freitag, 16. Februar 2018 11:57:00 UTC+1 schrieb Louis Pilfold:
>>>>>>
>>>>>> Hey Jony
>>>>>>
>>>>>> Would this involve some form of compile time type checking for these
>>>>>> values? If not we already have them in the form of tuples.
>>>>>>
>>>>>> @type result :: {:ok, string()} | {:error, string()}
>>>>>>
>>>>>> If you want compile time checks this would be more difficult. I've
>>>>>> experimented a little with compile time checks with macros, check it out
>>>>>> here -> https://github.com/lpil/sum
>>>>>>
>>>>>> Cheers,
>>>>>> Louis
>>>>>>
>>>>>> On Fri, 16 Feb 2018 at 10:33 <maen...@joshmartin.ch> wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> First I want to thank you all for your great work on the elixir
>>>>>>> language!
>>>>>>>
>>>>>>> Have there been some thoughts to introduce Tagged Unions into elixir?
>>>>>>> I would really love to use sum types like Either or simple enums in
>>>>>>> my daily work and have some support of the language in handling them.
>>>>>>>
>>>>>>> What do you think about this?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Jony
>>>>>>>
>>>>>>> --
>>>>>>> You rece

Re: [elixir-core:7895] Introduce Sum Types

[Louis Pilfold]

Hi

I started to implement such a library, but I would much prefer to use an
existing one. I was unable to find any, wild you be able to share some
links?

Thanks,
Louis

On Fri, 23 Feb 2018, 18:09 OvermindDL1, <overmind...@gmail.com> wrote:

> There are some library that add sum types to Elixir that do 'some'
> compile-time checks (like case's and so forth).  It would be useful built
> in to elixir (though not any of the current library implementations) but
> the libraries already do support much of it.
>
>
> On Friday, February 16, 2018 at 6:35:03 AM UTC-7, Ben Wilson wrote:
>>
>> 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 16, 2018 at 6:38:07 AM UTC-5, maen...@joshmartin.ch
>> wrote:
>>>
>>> Hey Louis,
>>>
>>> I think it should include compile time checks. Mostly I would expect
>>> those for function headers, case blocks and with blocks.
>>>
>>> Dialyzer already checks many of those conditions, but I would like to go
>>> a step further.
>>> Your mentioned library looks really interesting. Making it work together
>>> with existing type specifications would be really cool.
>>>
>>> With for example structs, I can achieve safety really easy by adding 
>>> *%Struct{}
>>> = my_input* to the function header.
>>>
>>> I would like to have a mechanism that works similarly, but additionally
>>> checks uncovered types of a sum. (If you would for example not cover the
>>> None of a Maybe)
>>>
>>> I think that this could tremendously improve the code quality.
>>>
>>> Cheers,
>>> Jony
>>>
>>> Am Freitag, 16. Februar 2018 11:57:00 UTC+1 schrieb Louis Pilfold:
>>>>
>>>> Hey Jony
>>>>
>>>> Would this involve some form of compile time type checking for these
>>>> values? If not we already have them in the form of tuples.
>>>>
>>>> @type result :: {:ok, string()} | {:error, string()}
>>>>
>>>> If you want compile time checks this would be more difficult. I've
>>>> experimented a little with compile time checks with macros, check it out
>>>> here -> https://github.com/lpil/sum
>>>>
>>>> Cheers,
>>>> Louis
>>>>
>>>> On Fri, 16 Feb 2018 at 10:33 <maen...@joshmartin.ch> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> First I want to thank you all for your great work on the elixir
>>>>> language!
>>>>>
>>>>> Have there been some thoughts to introduce Tagged Unions into elixir?
>>>>> I would really love to use sum types like Either or simple enums in my
>>>>> daily work and have some support of the language in handling them.
>>>>>
>>>>> What do you think about this?
>>>>>
>>>>> Cheers,
>>>>> Jony
>>>>>
>>>>> --
>>>>> 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/4052d8d9-6eda-46c9-b259-fb0f2e041120%40googlegroups.com
>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/4052d8d9-6eda-46c9-b259-fb0f2e041120%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/d1ac20e5-9198-47d1-91c4-cf6d6b0e733a%40googlegroups.com
> <https://groups.google.com/d/msgid/elixir-lang-core/d1ac20e5-9198-47d1-91c4-cf6d6b0e733a%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/CABu8xFC0kWY2ncPW0tm5MbyMj8WFa%2BD2v6bBamdB-1fyk7qu5A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:7887] Coverage by default

[Louis Pilfold]

Hi Yordis

As a counterpoint if this was included by default I would be removing it in
every project. I would prefer a minimal base that users can add to easily.

Cheers,
Louis

On Sat, 17 Feb 2018 at 11:41 Yordis Prieto  wrote:

> I found myself adding excoveralls in every single project that I do.
>
> Wouldn't be better to add such of tooling by default with the testing
> tools?
>
>
>
>
> P.S: even ex_doc is the same situation, every project I add the deps.
>
> --
> 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/af2aaee3-fbe8-4838-a53f-17a9eca8318e%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/CABu8xFAppO4%2BqEAcsmnV2ydRbng8L4dSxYU2d_YDbd-o5iNuSQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:7882] Introduce Sum Types

[Louis Pilfold]

Hey Jony

Would this involve some form of compile time type checking for these
values? If not we already have them in the form of tuples.

@type result :: {:ok, string()} | {:error, string()}

If you want compile time checks this would be more difficult. I've
experimented a little with compile time checks with macros, check it out
here -> https://github.com/lpil/sum

Cheers,
Louis

On Fri, 16 Feb 2018 at 10:33  wrote:

> Hi all,
>
> First I want to thank you all for your great work on the elixir language!
>
> Have there been some thoughts to introduce Tagged Unions into elixir?
> I would really love to use sum types like Either or simple enums in my
> daily work and have some support of the language in handling them.
>
> What do you think about this?
>
> Cheers,
> Jony
>
> --
> 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/4052d8d9-6eda-46c9-b259-fb0f2e041120%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/CABu8xFDq1ck4HbQpb9SEaQ_AEK9Wk1a2132Qf_4KTnVgOx4b8Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:7861] Proposal: Add assert_received_exactly to ExUnit

[Louis Pilfold]

You could just get the entire mailbox as a list and then. assert mailbox ==
[1, 2, 3]
No extra macros required.

Cheers,
Louis

On Sun, 11 Feb 2018, 15:59 José Valim,  wrote:

> How is that different from asserting each of them was received followed by
> a refute_received _? My concern about such helper is that it may imply an
> ordering which we likely won’t assert. Although one could argue the same
> about multiple assert_received calls.
>
> On Sun, Feb 11, 2018 at 16:04 Tobias Pfeiffer  wrote:
>
>> Hello everyone,
>>
>> I've happily been using a little helper for quite some time and Devon
>> liked it as well so thought might propose it:
>>
>> I often want to make sure that a bunch of messages were received but
>> exactly these messages and no more.
>>
>> Enter assert_received_exactly - it gets a list of expected messages and
>> it expects that each of them arrives no more than specified. (as always
>> sorry if something like this has been proposed before, haven't seen
>> anything)
>>
>> E.g.
>>
>> assert_received_exactly [:foo, :foo, :bar]
>>
>> passes if we received :foo 2 times and :bar one time. It fails if we
>> receive :foo or :bar more often or less often.
>>
>> Other usage example at [1].
>>
>> In the current implementation [2] receiving :baz won't fail the test as
>> only expected values are checked. This is currently done because there
>> are some messages being received that have nothing to do with the
>> current thing under test (I stub out some interactions with dummy
>> modules that send messages instead of doing work like [3]).
>>
>> I realize it's a very thin wrapper atm but having it part pf ExUnit
>> would probably still help people and make tests better overall.
>>
>> Happy to try & convert it to a macro and PR it if this helper is desired
>> :) (probably also with more custom error messages)
>>
>> Thanks for considering and for great community work and a great language!
>> :)
>> Tobi
>>
>> [1]
>>
>> https://github.com/PragTob/benchee/blob/3b60c17b067a7e7503cb0fb6e40bdc92ffde3fbd/test/benchee/benchmark/runner_test.exs#L854-L867
>> [2]
>>
>> https://github.com/PragTob/benchee/blob/master/test/support/test_helpers.ex#L23-L29
>> [3] https://devonestes.herokuapp.com/my-new-favorite-elixir-testing-trick
>> --
>> 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/e9f08407-830b-0e38-db5d-34d0672f247c%40gmail.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
>
>
> *José Valimwww.plataformatec.com.br
> Founder and Director of R*
>
> --
> 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/CAGnRm4JunuWKNwUkuqPD6-fOCLC_WZDLas%2BsmKHE4L978uNzMg%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/CABu8xFDhvvijR%3DETv7TFP7cODfgAFGjGjn5iKGpNfTP_aa%3DV-Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:7857] mix deps.add || mix add package

[Louis Pilfold]

Hi all

Alternatively you could investigate building your project with rebar3, the
standard Erlang build tool. It uses a machine readable file for project
configuration.

Cheers,
Louis

On Fri, 9 Feb 2018, 13:42 Norbert Melzer, <timmel...@gmail.com> wrote:

> Because its so much nicer to configure the build via real code.
>
> If it were necessary to know the numbers of solarflares, I could check an
> API and act accordingly before building the project. You can't do that with
> a JSON file.
>
> But it also enables you, to actually have a plain file, containing nothing
> but a list and load it from the mix.exs file. This additional file could
> then be maintained by whatever tool you choose.
>
> niahoo osef <ludovic.dembl...@gmail.com> schrieb am Fr., 9. Feb. 2018 um
> 14:30 Uhr:
>
>> Hi everyone. I would like to know why Mix developers choose not to use a
>> pure data file for dependencies and application metadata, unlike many other
>> languages ?
>>
>> Thank you
>>
>> Le 9 févr. 2018 20:20, "Louis Pilfold" <louispopin...@gmail.com> a
>> écrit :
>>
>>> Hi Zareh
>>>
>>> Given the mix.exs file is not a machine readable format how would this
>>> be implemented? Any Elixir could can be used to build the `project/0`
>>> function.
>>>
>>> Cheers,
>>> Louis
>>>
>>> On Fri, 9 Feb 2018 at 13:09 Zareh Petrossian <zer...@gmail.com> wrote:
>>>
>>>> Add packages at a terminal without having to go through a text editor...
>>>>
>>>> i.e.
>>>>
>>>> mix deps.add plug
>>>>
>>>> or
>>>>
>>>> mix do deps.add plug, deps.get, deps.compile
>>>>
>>>> I think the value/reasoning for this is quite self explanatory.
>>>>
>>>> --
>>>> 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/122f7d0d-4de1-4848-b0a0-926df263b67d%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/elixir-lang-core/122f7d0d-4de1-4848-b0a0-926df263b67d%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/CABu8xFDCURB6_8Jvv6QmTF3mYhx%3DJcvuG8OibG80HJFg41HAtA%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/elixir-lang-core/CABu8xFDCURB6_8Jvv6QmTF3mYhx%3DJcvuG8OibG80HJFg41HAtA%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/CAOcJokoGhPB_t0XY8rv-Au1i5LvuNN7eEz5kwdaNtRDfCA9Prw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/elixir-lang-core/CAOcJokoGhPB_t0XY8rv-Au1i5LvuNN7eEz5kwdaNtRDfCA9Prw%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/CA%2BbCVsum2_mkdYr%2BFbjifBr5e8QWiuthaY563iVq9bTzLuQkrg%40mail.gmail.com
> <https://groups.google.com/d/msgid/elixir-lang-core/CA%2BbCVsum2_mkdYr%2BFbjifBr5e8QWiuthaY563iVq9bTzLuQkrg%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/CABu8xFBDWqEzGPdTmFAekUYuxLq4Dy7zG_jDhKyRUSBp5SNRBg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:7806] Proposal: [ExUnit] with_application_env(key, value, update_fun, fun)

[Louis Pilfold]

Hey

Mix config is global mutable state, so I'm not sure how you could handle
this asynchronously.

Personally I prefer to avoid mix config where possible an instead pass
values down through the supervision tree. :)

Cheers,
Louis

On Fri, 26 Jan 2018, 16:03 Michael Schaefermeyer, <
michael.schaeferme...@gmail.com> wrote:

> It definitely is, thanks Louis!
>
> Figuring that this is something other people might need as well I wondered
> if it was worthwhile to put it ExUnit directly (and make it work with
> async).
>
>
> Am Freitag, 26. Januar 2018 16:41:47 UTC+1 schrieb Louis Pilfold:
>
>> Hi Michael
>>
>> I've written a tiny lib for this -> https://github.com/lpil/temporary-env
>>
>> Perhaps you might find this useful :)
>>
>> Cheers,
>> Louis
>>
>> On Fri, 26 Jan 2018, 14:24 Michael Schaefermeyer, <
>> michael.sc...@gmail.com> wrote:
>>
> Hey all,
>>>
>>> I regularly find myself changing the Application configuration in tests
>>> to temporarily adjust a setting (i.e. when using Bypass and changing the
>>> configured endpoint for HTTP requests).
>>>
>>> My current workflow looks as follows:
>>>
>>> test "something" do
>>>   old_env = Application.get_env(:app, Module)
>>>   new_env = Keyword.put(old_env, :key, value)
>>>
>>>   Application.put_env(:app, Module, new_env)
>>>
>>>   # Do something that reads the config
>>>   Application.put_env(:app, Module, old_env)
>>> end
>>>
>>> Besides being quite repetitive it disallows async tests, as another test
>>> might be reading from the Application environment while this test is
>>> running.
>>>
>>> Ideally, ExUnit would allow me to temporarily change the Application
>>> environment in a async-safe way:
>>>
>>> test "something" do
>>>   with_application_env :app, Module, fn(config) -> Keyword.put(config, :
>>> key, value), fn ->
>>> # Do something that reads the config
>>>   end
>>> end
>>>
>>> Of course I could make the configuration module configurable and use
>>> something other than Application. The reason I am still suggesting this is
>>> that I feel like configuring your app via Application is still the way to
>>> go and I wouldn't want to diverge from that standard just for tests.
>>>
>>> Hope that makes sense. I would love to hear your thoughts.
>>>
>>> Thanks,
>>> Michael
>>>
>>> --
>>> 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/4b863c84-2062-42f3-b0a0-92b1d122f40c%40googlegroups.com
>>> <https://groups.google.com/d/msgid/elixir-lang-core/4b863c84-2062-42f3-b0a0-92b1d122f40c%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/4eacd1d3-0d61-499a-bf82-076988799a53%40googlegroups.com
> <https://groups.google.com/d/msgid/elixir-lang-core/4eacd1d3-0d61-499a-bf82-076988799a53%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/CABu8xFD%2BqTPzmJzt36PoC%3Dqm8gTZZUpwcemN%3DM5HMxn_nF_dUw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:7804] Proposal: [ExUnit] with_application_env(key, value, update_fun, fun)

[Louis Pilfold]

Hi Michael

I've written a tiny lib for this -> https://github.com/lpil/temporary-env

Perhaps you might find this useful :)

Cheers,
Louis

On Fri, 26 Jan 2018, 14:24 Michael Schaefermeyer, <
michael.schaeferme...@gmail.com> wrote:

> Hey all,
>
> I regularly find myself changing the Application configuration in tests to
> temporarily adjust a setting (i.e. when using Bypass and changing the
> configured endpoint for HTTP requests).
>
> My current workflow looks as follows:
>
> test "something" do
>   old_env = Application.get_env(:app, Module)
>   new_env = Keyword.put(old_env, :key, value)
>
>   Application.put_env(:app, Module, new_env)
>
>   # Do something that reads the config
>   Application.put_env(:app, Module, old_env)
> end
>
> Besides being quite repetitive it disallows async tests, as another test
> might be reading from the Application environment while this test is
> running.
>
> Ideally, ExUnit would allow me to temporarily change the Application
> environment in a async-safe way:
>
> test "something" do
>   with_application_env :app, Module, fn(config) -> Keyword.put(config, :
> key, value), fn ->
> # Do something that reads the config
>   end
> end
>
> Of course I could make the configuration module configurable and use
> something other than Application. The reason I am still suggesting this is
> that I feel like configuring your app via Application is still the way to
> go and I wouldn't want to diverge from that standard just for tests.
>
> Hope that makes sense. I would love to hear your thoughts.
>
> Thanks,
> Michael
>
> --
> 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/4b863c84-2062-42f3-b0a0-92b1d122f40c%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/CABu8xFDWPftNWFJGeRNXRsXRNXXL7NjKxEKkLn%3DtcnrFqchjRw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:7793] [Proposal] Add async functions definitions

[Louis Pilfold]

Hi Pedro

I would worry that this would result in this use of the Task module
becoming the de-facto way to do work concurrently in Elixir. I think that
the majority of the time there's a better solution, likely on that involves
supervision.

I think the need for a shorthand for performing work concurrently is not
needed in the same way as in Python etc as it's OK to perform IO that
blocks your thread as only one request/item of work is being served by that
thread.

Cheers,
Louis

On Tue, 23 Jan 2018 at 15:01 Pedro Medeiros  wrote:

> Hi,
>
> I'm writing this proposal based on what I've been doing with
> Python/Javascript. A way ppl on those communities are doing asynchronous
> call nowadays is by declaring an async function and if there is a need to
> wait for its result calls the function await. Once we have the module Task
> that is capable of handling mostly user cases about async/await feature on
> those languages. I think we can add async to the function definition to
> implement
>
> defmodule Foo do
>   async def bar(x)# code
>   endend
>
>
>
> And on the code by calling Foo.bar/1 we return a Task. And by calling
> Task.async Foo.foo(1) the result can be returned.
>
> the main benefits on having an approach like that is basically code
> readability when it is necessary to run a single function as a separate
> process. today that can be done with something like that
>
> task = Task.async(fn ->
>   Foo.bar(:arg)end)Task.await(task)
>
>
> or
>
> task = Task.async(Foo, :bar, [:arg])Task.await(task)
>
>
> Also another benefit is having a syntax more similar to other languages.
> This can make Elixir more welcoming for people from other communities such
> as python or javascript.
> --
> Pedro Medeiros
> --
> Cel: +55 (21) 9914-86898
> Email: pedro...@gmail.com
>
> Beautiful is better than ugly,
> Explicit is better than implicit,
> Simple is better than complex,
> Complex is better than complicated.
>
> The Zen of Python, by Tim Peters
>
> --
> 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/CAJbPmJM_TAtuV5b39ZaC1gd8njtHCyk3xe2_%2BfdgfwhOcA-L7Q%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/CABu8xFB6QAVfM%2Bg4LCKFGDBQu6opGiNuXb1Fv-YZ0pEoNaPr4A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:7721] Proposal: mix format to work with EEx files

[Louis Pilfold]

Hey

How would the formatter know what format to use for eex files? It's often
HTML but there is no guarantee that is the case.

Cheers,
Louis

On Fri, 29 Dec 2017, 23:40 Steven Blowers,  wrote:

> Hello,
>
> Thanks to those involved for their recent work with mix format which I
> have been trying out on 1.6rc0.
>
> I find myself now wanting to format *everything* in my current Phoenix
> project, including my EEx templates.
>
> The formatter does not currently do this, I was wondering if would even be
> the correct decision for the formatter to also do EEx files,
> as they are so different to a regular Elixir file and I should instead be
> looking for a HTML formatter which can handle embedded code in it?
>
> The downside to that would then be setting up two formatters for one
> project, the second one most likely being setup with Node/NPM,
> which I guess isn't so bad as most Phoenix projects already have Node/NPM
> to handle assets.
>
> What are people's thoughts on this?
>
> Steven
>
> --
> 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/8ffda124-215a-4dc0-8ed7-2b6fc57e1892%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/CABu8xFCbrFE3hcMhQymHa5xey7hJ%2Bue%3DVp51wEQvFihRh1hNEA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:7693] Move Dependency Build files into a seperate location

[Louis Pilfold]

Hi gang

There's a mix task that will remove compiled application code (clean, I
think). Run this before caching the build directory :)

Cheers,
Louis

On Tue, 19 Dec 2017, 04:59 Paul Schoenfelder, 
wrote:

> Could you clarify what the issue is? You haven't specified under what
> circumstances caching is a problem or with what tools.
>
> Paul
>
> On Mon, Dec 18, 2017 at 10:53 PM  wrote:
>
>> The _build folder contains all build artifacts for external dependencies
>> and internal application code. This means that caching this folder is a
>> pain.
>> If I could simply cache the external dependency build artifacts
>> separately to the internal application artifacts, this would solve my
>> problem. To do this, I think the artifacts should be kept in a seperate
>> location such as _build//deps/...
>>
>>
>>
>> Want to get insights, recommendations and answers from top consultants
>> for free? Head to Discussions  to ask
>> questions and find answers.
>>
>> ———
>> This email is intended for the sole use of the intended recipient(s) and
>> may contain information that is confidential and/or privileged.  Any review
>> or distribution by any other person is prohibited.  If you are not an
>> intended recipient, please immediately contact the sender and delete all
>> copies of this email message
>>
>> --
>> 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/ac3428e7-f626-4392-ab3a-9aa32a23face%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/CAK%3D%2B-Tsp3Q6HbzrE1kJ0Th1GUAxreZyVckU7d4kFY_8JfmAoCg%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/CABu8xFBpCQ9M6c%2B5%3D1vdqqkyaf0kKxfw6Z0xekyxfj7Sdq6S9w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:7551] [Proposal] operator =~ should support maps

[Louis Pilfold]

Hey

The `assert` macro handles MatchError as well as true/false.

>  Ideally, in the assertion results, it would highlight the failing
key/values as well.

This would be a nice addition to ExUnit. I would rather see this than any
addition to =~

Cheers,
Louis

On Wed, 18 Oct 2017 at 13:43  wrote:

> Yes, but that throws a MatchError exception if not satisfied, not a
> true/false.  Ideally, in the assertion results, it would highlight the
> failing key/values as well.  Primarily for testing, but also a quick way to
> test for the presence of multiple key/values in larger maps.
>
>
> On Wednesday, October 18, 2017 at 12:14:00 AM UTC-5, Andrew Timberlake
> wrote:
>
>> You can do that with pattern matching,
>>
>> assert %{field1: "foo", field2: "bar"} = data
>>
>
>> On 18 Oct 2017, 05:01 +0200, jer...@companykitchen.com, wrote:
>>
> I think it would be useful if =~ supported maps.  =~ would return true if
>> the key/values in the right hand map were also contained in the left-hand
>> map.  I think this would be especially useful for testing, as you could
>> check that the result matched a subset of the map, rather than the whole
>> map.
>>
>> e.g.
>> data = Repo.insert!(src)
>> # data = %Data{id: 25, field1: "foo", field2: "bar", inserted_at:
>> ~N[2017-01-01], updated_at: ~N[2017-01-01]}
>> assert data =~ %{field1: "foo", field2: "bar"}  # true
>>
>> --
>> 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/7eaabb77-6c7a-4fcb-a74a-fc303f5ace26%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/fb23650e-c3f4-4694-86e1-62cdc2b9e103%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/CABu8xFC3%3DQRH_t8_J6LFWe07WCGHd7WxzhVpJ6um2fxB89vB9A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:7464] [Proposal] Converting @type/@spec to contract/asserts at compile time?

[Louis Pilfold]

Heya

You could write a library that does this rather than modifying Elixir. It
would be a cool project :)

Cheers,
Louis

On Fri, 29 Sep 2017, 18:06 ,  wrote:

> Hi all!
>
> I increasingly find myself writing more or less exactly same logic as in
> @type/@spec in body of the function to check incoming arguments.
>
> Would it be helpful if Elixir compiler could wrap function into assert
> check for incoming arguments and also result generated based on typespec?
>
> I think it would be very useful for
>
> - while running unit tests immediately see where components interaction
> breaks
> - keeping unit tests data in sync while developing - creates more crashes
> when some stub/test data does not comply with changed logic in function
> - running system and checking where it breaks the contracts between
> components in run-time/while debugging (dyalizer does a great job to
> extract information during static analysis phase, but runtime can provide
> more incorrect data :)
> - encourage writing more typespecs because benefits of doing so will be
> visible immediately and not when (occasionally) dyalizer will be run. So
> make it type specification first class citizen that is not just for
> documenting code, but also to enforce constraints.
>
> I personally would also love to have possibility for extended typespec
> that would allow also specify relation between arguments too. Like
> assert(arg1 + arg2 > 0).
>
> It seems that it may be achieved mostly by rewriting def/defp macros and
> embedding asserts code generated from @spec around function body.
>
> This will slow down the execution of code and should be compiler option to
> turn it on/off for production/dev/testing environment separately with on
> setting in development/testing by default.
>
> What do you think?
>
> /Gaspar
>
> --
> 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/638bb1fe-5276-49a3-9013-a784625226ea%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/CABu8xFCnA04e-RpaQQqxetDw8d1O%2BT4Q1kWc9WH8r9b5%2BuqF%2Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:7388] easy dependencies installation

[Louis Pilfold]

Hiya

If you go down that route you'd lose all formatting, comments, etc, which
is a shame.

Have a go, no reason this couldn't be a third party mix task rather than an
official built-in one.

Cheers,
Louis

On Fri, 18 Aug 2017 at 12:44 Vitaly Shvedchenko <
vitaly.shvedche...@gmail.com> wrote:

> But, Louis, isn't abstract syntax tree a way of safely modify elixir code?
> For example I could quote all the mix.exs file, find dependencies tuple,
> modify it and unquote it back.
>
>
> On Wednesday, July 19, 2017 at 12:37:57 AM UTC+3, Louis Pilfold wrote:
>
>> Hey Vitaly
>>
>> The dependency file for mix is an Elixir program rather than just a
>> simple JSON file. There's no way reliably and safely programatically modify
>> the mix.exs file as a result.
>>
>> Cheers,
>> Louis
>>
>> On Tue, 18 Jul 2017 at 22:17 Vitaly Shvedchenko <vitaly.sh...@gmail.com>
>> wrote:
>>
> Hi guys,
>>>
>>> I'd like to suggest a feature and may be implement it. I've found
>>> somebody proposed this feature earlier, but it was a long time ago and
>>> there was not a single reply to it. So I'd try one more time for that poor
>>> guy and for me.
>>>
>>> When you develop elixir project and adding new dependencies to the
>>> project, you always have to find needed package onlline, find out it's
>>> latest version number and put it in your mix.exs dependencies for yourself.
>>> What could be helpful is some equivalent of a
>>> npm install --save
>>> command from nodejs world. It would be like
>>> mix deps.install package_name
>>> What this command has to do is just
>>> 1. check if hex is installed, propose to install it if it is not,
>>> 2. get the hex package info, parse its version,
>>> 3. put it in mix.exs file (with some conventional semantic versioning
>>> pattern like "~> x.y")
>>> 4. and call mix deps.get—thats it!
>>> It probably would not put the dependency in OTP applications to start
>>> list, but still it is much easier way of installing dependencies.
>>>
>>> I guess there is some conventional reasons to not implement such way of
>>> installing new dependencies, but it's not obvious for me and many other
>>> people why there is no such option.
>>>
>>> Thanks! Will be glad to have some feedback.
>>>
>>> --
>>> 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/9daf03ef-a9a6-44d2-b7d5-68c345b42d76%40googlegroups.com
>>> <https://groups.google.com/d/msgid/elixir-lang-core/9daf03ef-a9a6-44d2-b7d5-68c345b42d76%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/adcb4ac0-aea5-472e-ba07-481c6e9aeb2a%40googlegroups.com
> <https://groups.google.com/d/msgid/elixir-lang-core/adcb4ac0-aea5-472e-ba07-481c6e9aeb2a%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/CABu8xFBYN0geu%2Bu7uvT4rhSXmszTgzFb0q-b9BtewEpJxCVOUw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:7381] StreamData: data generation and property testing for Elixir

[Louis Pilfold]

Hey Andrea

Looks really nice, looking forward to trying it out.

That `check all` trick used to sort-of get a variable arity macro is pretty
neat, will have to remember that one :)

Cheers,
Louis

On Fri, 11 Aug 2017 at 16:01 Andrea Leopardi  wrote:

> Hello folks,
>
>
> I am super excited to finally share what I've been working on in the last
> few months: StreamData , an
> Elixir library for data generation and property testing. StreamData is a
> candidate to be included in Elixir itself but we wanted to start off with a
> library to first give people the chance to give it a try and to get the
> interface right (we did something similar with GenStage
> , which ended up remaining
> outside of Elixir core).
>
> StreamData is still in its infancy but it's ready to be tested by a wider
> audience (let's say it's exiting alpha and entering beta), so I invite the
> Elixir community to give it a try. Open issues, send PRs, and spread the
> word!
>
>
> https://hex.pm/packages/stream_data
>
>
> Andrea
>
>
> (link to ElixirForum announcement:
> https://elixirforum.com/t/streamdata-data-generation-and-property-testing-for-elixir/7715
> )
>
> --
> 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/bcd5fd0b-b224-4b74-804e-3d94ab020511%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/CABu8xFDPGu0eh-7DuytKeY_%2Bci%3DnKm4mWDCSBkNhN-33gjvzyQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:7295] easy dependencies installation

[Louis Pilfold]

Hey Vitaly

The dependency file for mix is an Elixir program rather than just a simple
JSON file. There's no way reliably and safely programatically modify the
mix.exs file as a result.

Cheers,
Louis

On Tue, 18 Jul 2017 at 22:17 Vitaly Shvedchenko <
vitaly.shvedche...@gmail.com> wrote:

> Hi guys,
>
> I'd like to suggest a feature and may be implement it. I've found somebody
> proposed this feature earlier, but it was a long time ago and there was not
> a single reply to it. So I'd try one more time for that poor guy and for
> me.
>
> When you develop elixir project and adding new dependencies to the
> project, you always have to find needed package onlline, find out it's
> latest version number and put it in your mix.exs dependencies for yourself.
> What could be helpful is some equivalent of a
> npm install --save
> command from nodejs world. It would be like
> mix deps.install package_name
> What this command has to do is just
> 1. check if hex is installed, propose to install it if it is not,
> 2. get the hex package info, parse its version,
> 3. put it in mix.exs file (with some conventional semantic versioning
> pattern like "~> x.y")
> 4. and call mix deps.get—thats it!
> It probably would not put the dependency in OTP applications to start
> list, but still it is much easier way of installing dependencies.
>
> I guess there is some conventional reasons to not implement such way of
> installing new dependencies, but it's not obvious for me and many other
> people why there is no such option.
>
> Thanks! Will be glad to have some feedback.
>
> --
> 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/9daf03ef-a9a6-44d2-b7d5-68c345b42d76%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/CABu8xFAmKrBVsFNtEtzocY0pXCeSzFa7epxP7Fm0VdFVg7x1nA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Louis Pilfold]

Hey Amos

As I understand it the ordering of maps is an Erlang implementation detail
that is not to be relied upon. If you want an ordered dictionary a map
probably is not the correct data structure for you.

Cheers,
Louis


On Wed, 15 Feb 2017 at 14:35 Amos King  wrote:

> Before jumping on this should we be asking why the decision was made to
> not sort if there are more than 32 keys? Maybe there is a performance
> concern, and if we want sorted keys we should be sending a different
> message?
>
> Amos King
> Owner
> Binary Noggin
> http://binarynoggin.com #business
> http://thisagilelife.com #podcast
>
> ===
> I welcome VSRE emails. Learn more at http://vsre.info/
> ===
>
>
> On Tue, Feb 14, 2017 at 7:41 PM, Ben Wilson 
> wrote:
>
> This has my vote as well. It would make visually inspecting maps a lot
> easier.
>
> On Tuesday, February 14, 2017 at 7:36:05 PM UTC-5, Onorio Catenacci wrote:
>
> +1 Eric
>
> --
> 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/934ffbee-44a6-40fb-9ecf-e24d48624f3f%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/CAJr6D4S81ZqQ%2BaZQrw_rohpPXxwBpUWz1WsAEUZ82fjT02U7Pg%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/CABu8xFDzE7u%2BbSHgR4Z5xxLHtFox44LQq3y2ZaDsamZjdLzSTA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:6666] I think the new 1.4 warning about missing () on zero arity functions is a cure that's worse than the disease

[Louis Pilfold]

I personally think this is clearer, and I don't feel this is clearer. With
this I think it is easier to tell when computation is happening- previously
it could be hidden behind what looks like variables.

Cheers,
Louis

On Sat, 3 Dec 2016, 04:42 Dave Thomas,  wrote:

> I’ve been loving 1.4 for a few weeks now, but I am bugged by the new
> warning:
>
>  warning: variable "int" does not exist and is being expanded to "int()", 
> please use parentheses to
>remove the ambiguity or change the variable name
>
> Partly it is because it makes my code a lot uglier. For example, in
> quixir, instead of
>
> test "two plain types" do
>   ptest a: int, b: list do
>​ assert is_integer(a)
> assert is_list(b)
>   end
> end
>
> I now have to write:
>
> test "two plain types" do
>   ptest a: int(), b: list() do
>
>
>. . .
>
> Ugh. Even worse, the premise of the warning seems wrong. It assumes int
> is a variable, which doesn’t exist. But it *does* know that int is a
> function, because if I misspell it and put ()s on, I get a compilation
> error. So why can’t it just do that: is a bare name is encountered that
> isn’t a variable, just internally tack on the ()s are see what happens.
> Which I think is the old way.
>
> Basically, what compelling problem drove this change? It isn’t an issue I
> ever had before, and the change seems to make my code worse.
>
> Dave
> ​
>
> --
> 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/22ad983c-0917-4425-abbe-a6e954ae3b61%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/CAM-pwt7JgYzWnC6y1-ELHj%2BOeaJDuDCamAxJmktdeYRdLaYFEA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:6400] [Proposal] List.unwrap/1

[Louis Pilfold]

What's the difference between this and List.flatten ?

Cheers,
Louis

On 25 Sep 2016 23:00, "Chris Keele"  wrote:

> List.unwrap/1
> 
> is a simple compliment to List.wrap/1––it walks a nested list and unwraps
> any extraneous wrappers it finds, eg: [[:a]] -> [:a].
>
> I mostly find it useful for cleaning up after nested list transforms, but
> always manage to implement it wrong the first few times, so I thought I'd
> throw it out there as a general list utility.
>
> --
> 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/3da5323f-585f-4068-8ef0-
> 1865d3a75fd0%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/CAM-pwt6kAJHnemaTihDLBLuXTFzc%3D%3D_W_9%3DLY4b3KEUSNaOJmA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:6388] Re: Deprecate 'single quotes for char lists'

[Louis Pilfold]

Hey

I'm +1 so long as single quotes are not then used for strings. I'd much
rather avoid disagreements about which style of string syntax to use.

Cheers,
Louis

On 23 Sep 2016 18:17, "Chris Keele"  wrote:

> I have no strong opinions on this–although I do hope that useful *'* character
> will eventually be reclaimed for some purpose. I assume inspecting *'abc'*
> as *~c"abc"* implies that the usual newcomer confusion of inspecting an
> integer list and seeing a 'string' will be a somewhat more searchable
> problem, which is nice.
>
> I did want to observe that, now that I know you can create charlists with
> sigils, I'll probably never use *'* again, because to me *~c[foobar]* is
> much more representative of the underlying data structure. Perhaps this
> could also be how it inspects, to enforce the 'list' connotation?
>
> --
> 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/22f6bc15-b232-4d04-87db-
> 9dbc950a069c%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/CAM-pwt7jZu3WoWTBM%2BDQrrjDwy0Mb2i9DNcVauhakYbh2CMHfg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:6338] Automatically infer the list of applications

[Louis Pilfold]

Hiya

I'm unsure about this proposal. I do think that the name OTP
applications is unclear. There are other Erlang OTP applications that
are started when not in this list, and the skipped and included
applications are OTP applications as well.

How does one determine if a production dependency is an application or not?

Cheers,
Louis

On 20 September 2016 at 10:01, José Valim
 wrote:
> One of the most confusing topics when it comes to building Mix projects and
> releases is in figuring out the list of applications. The workflow for
> adding a dependency usually requires adding the dependency to the list of
> deps and then adding its application to the list of applications.
>
> Since this was a common source of confusion, we wrote a blog post discussing
> the common scenarios and rationale:
> http://blog.plataformatec.com.br/2016/07/understanding-deps-and-applications-in-your-mixfile/
>
> However, I believe we should still attempt to simplify this workflow. This
> is such a proposal.
>
> The idea is to automatically inflect the list of applications by including
> all dependencies that are required in production. Overall, we will have:
>
> def application do
>
>   [otp_applications: [:logger],
>
>skipped_applications: [...],
>
>included_applications: [...]]
>
> end
>
>
> If the :applications key is is not provided, we will automatically inflect
> it by calculating:
>
> applications = ((all_apps_for_prod_deps ++ otp_applications) --
> included_applications) -- skipped_applications
>
> otp_applications - lists applications that come from erlang or elixir
> skipped_applications - dependencies that are listed in production but you
> want to skip during releases (mutually exclusive with :applications)
> included_applications - same meaning as today. applications you want to
> include in production but not start them
>
>
> I expect for the majority of cases developers won't need to pass the
> skipped_applications and included_applications flags, so we can skip them in
> generated templates. At the end, new apps will have only the following:
>
>
> def application do
>   # List only applications from Elixir and Erlang required in prod
>
>   [otp_applications: [:logger]]
>
> end
>
>
> Thoughts?
>
> José Valim
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Director of R
>
> --
> 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/CAGnRm4LWOsR5xiND%3D-Ty_NcFmFj3VfPstVs1mxTiTsbrf6g64Q%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/CAM-pwt6UgfnztEvSspErorQo3y337ZEjQ5Hho-FEWpxoJWFtnw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Louis Pilfold]

Hello!

What is the advantage of the new syntax? To me it seems it only serves to
obscure what is actually happening.
I don't think adding multiple ways to write the same thing will bring
anything other than inconsistency to the language, causing style squabbles
and giving newcomers one more irregularity memorise.

Side note: if this macro has a special syntax, does this mean I can also
use this syntax for my own macros?

Cheers,
Louis

On 15 Sep 2016 10:39, "Jaap Frolich"  wrote:

> Hi,
>
> @Jose: I would suggest this to be syntactic sugar to import functions from
> modules, that is converted behind the scenes to a call to import, only:
> [...].
> This will add complexity to the language, by creating a new way of
> importing, but in 99% you can use the new syntax, and only use the 'low
> level' syntax in macros or special use cases such as when you need
> 'except'. Another upside is that all the old code keeps working, but we
> have a nicer syntax for new code.
> I think it can incentivize people to only import the necessary functions
> and not import all if there is a nicer syntax to it.
>
> @Onorio: While an improvement, I like the proposed syntax more, because in
> my opinion import a single/a few functions should be the default, and not a
> special case (with using only).
>
> @Norbert: I am not really in favor of the `import _one/1,
> _2/1 from Module` syntax as I think it is less pretty and while it
> might be easier to implement, semantically it does not really makes sense
> to me / is intuitive.
>
> Thanks for thinking about this :) Love the language.
>
> Cheers,
>
> Jaap
>
>
>
> On Tuesday, September 13, 2016 at 2:54:20 PM UTC+8, José Valim wrote:
>>
>> 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
>>
>> 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-co...@googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/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/6c1b1e6e-822b-4540-be41-
> fa65322ed78b%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the 

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
>>
>> 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.

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

[Louis Pilfold]

Hi!

with is the right tool when you want this kind of error handling in these
function pipelines :)

Cheers,
Louis

On 15 Aug 2016 12:12, "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-core+unsubscr...@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/CAM-pwt4N2w6sqUOkemo-q--FrZKcrvNBPYMpBMb4A9O2qOWOhQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:6084] Maybe Add A Warning For Including Commas In ~w List

[Louis Pilfold]

Hey

How would I silence the warnings emitted when I have deliberate commas in a
w sigil?

Cheers,
Louis
On 12 Jul 2016 00:49, "Onorio Catenacci"  wrote:

> That is sort of the definition of "warning". If it were obviously wrong it
> would be a compiler error.
>
> Henrik N  wrote:
> >Is there precedent for warnings in Elixir about things that could be a
> mistake but could also be a valid use case?
> >
> >--
> >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/tmAESH8Nhz8/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/77dc7cd3-07b4-4ef1-8dfa-587587feb0ee%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/xmbipso4kehogg28mex2s1j3.1468280949540%40email.android.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/CAM-pwt5jjqbCNoYU%3DZkDuBMWcU7SwpuwpY7rwn_VBcjEMAUOGQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.