+1 > On Jul 30, 2019, at 20:40, eksperimental <[email protected]> wrote: > > `Function.identity/1`: I think you just hit the nail on the head with this > one. > > Nice middle ground > I'm +1 for this one. > > On Tue, 30 Jul 2019 12:46:53 -0400 > Allen Madsen <[email protected]> wrote: > >> I don't have a strong opinion on this function's inclusion. It's not >> mandatory that it live in Kernel though. It could exist on Function. >> >> Allen Madsen >> http://www.allenmadsen.com >> >> >>> On Tue, Jul 30, 2019 at 12:29 PM Chris McCord <[email protected]> wrote: >>> >>> I’m just catching up on this thread now, but I’m in the “not valuable >>> enough to be added” camp. I’ve personally never needed such an abstraction >>> – on my own or while teaching. Also, an anon function serves the purpose >>> when needed without introducing a new concept. From the beginner >>> perspective, I think `identify` adds more noise where it isn’t needed. Even >>> following this thread and reading other lang usage, I still find the name >>> awkward and struggle to see it being a net benefit to my code vs what I’d >>> happily write today. Given how trivial it is to return the value yourself >>> in a concise and clear way, I don’t think the value of it squatting in >>> kernel is enough to justify an addition to the std lib. >>> >>> On Jul 21, 2019, at 8:47 AM, Bruce Tate <[email protected]> wrote: >>> >>> I want to speak to the beginners argument. I am not guessing. I spend 6-8 >>> hours teaching and mentoring every week, and it's more when school is in. >>> Concepts are easier to teach when those concepts have names and big >>> concepts can be broken down into smaller ones. The students I teach are >>> about 80% new to FP and about 40% new to programming in general. >>> >>> I will take the advice of mixing in FP.identity if it cuts against the >>> grain of what Elixir is about. >>> >>> Thanks to all for making Elixir the best it can be... let's keep it civil. >>> I think it makes a lot of sense to take José's suggestion and collect some >>> of these concepts into a library and prove their worth there, to language >>> learners and otherwise. >>> >>> -bt >>> >>> On Mon, Jul 15, 2019 at 5:12 AM Andrea Leopardi <[email protected]> >>> wrote: >>> >>>> My 2 cents. To me a strong argument against this is that &identity/1 >>>> still looks confusing to newcomers with the capture syntax (how many "why >>>> can't I just write identity like in Js questions do we get after all), so >>>> summed with the other arguments against it makes me not want to add this to >>>> the language personally. >>>> >>>> On Mon, 15 Jul 2019 at 09:30, Masoud Ghorbani <[email protected]> >>>> wrote: >>>> >>>>> Isn't possible to have something like JavaScript arguments which >>>>> correspond with a list of parameters passed to function? >>>>> its more handy to lookup a parameter in a list or map until working with >>>>> a function to get a given parameter. >>>>> >>>>> On Tuesday, July 2, 2019 at 11:10:45 PM UTC+4:30, José Valim wrote: >>>>>> >>>>>> Thanks Chris, it is important that someone being counter arguments, >>>>>> even if they can be disproved. :) >>>>>> >>>>>> I definitely see how such a small function can be useful but, at the >>>>>> same time, I am not convinced about the name "identity". >>>>>> >>>>>> I found it curious that Clojure actually have an identity function >>>>>> because the definition of Identity they use when talking about values and >>>>>> change is a more complex one (and one that really stuck with me): >>>>>> >>>>>> *> By identity I mean a stable logical entity associated with a series >>>>>> of different values over time* >>>>>> >>>>>> https://clojure.org/about/state#_working_models_and_identity >>>>>> >>>>>> Of course, my interpretation above is likely uncommon and there are >>>>>> other interpretations of identity that would fit nicely. >>>>>> >>>>>> Anyway, to move the discussion forward, can someone do a more complete >>>>>> survey on what this function are called in many of the other languages? I >>>>>> just want to make sure we do our due diligence before adding it to the >>>>>> language. >>>>>> >>>>>> Thank you, >>>>>> >>>>>> *José Valim* >>>>>> www.plataformatec.com.br >>>>>> Skype: jv.ptec >>>>>> Founder and Director of R&D >>>>>> >>>>>> >>>>>> On Tue, Jul 2, 2019 at 8:25 PM Christopher Keele <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Derp, I knew that. Good point. >>>>>>> >>>>>>> On Tue, Jul 2, 2019 at 9:55 AM Michał Muskała <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Because Elixir is a lisp-2 language, variables and functions are in >>>>>>>> different "namespaces". This means you can have local variables with >>>>>>>> names >>>>>>>> of local functions without any issues, but it also means you need >>>>>>>> different >>>>>>>> syntax when you want to call a function contained in a variable. Or >>>>>>>> formulated differently - variables can't shadow functions. For example, >>>>>>>> consider: >>>>>>>> >>>>>>>> bar = &foo/0 >>>>>>>> bar.() #=> 1 >>>>>>>> bar() #=> 2 >>>>>>>> def foo(), do: 1def bar(), do: 2 >>>>>>>> >>>>>>>> Having a Kernel.id/1 function would not preclude you from using >>>>>>>> variables called id. >>>>>>>> >>>>>>>> >>>>>>>> Michał. >>>>>>>> On 2 Jul 2019, 18:41 +0200, Christopher Keele <[email protected]>, >>>>>>>> wrote: >>>>>>>> >>>>>>>> I'd cast my vote against this. The proposal seems to be: >>>>>>>> >>>>>>>> 1. Create a function named 'id' or some such >>>>>>>> 2. Put it in the Kernel namespace (so it need not be prefixed) >>>>>>>> >>>>>>>> I've been doing a lot of python lately and they have a lot of things >>>>>>>> like this, including the same 'filter' global function mentioned in >>>>>>>> this >>>>>>>> thread. >>>>>>>> >>>>>>>> Points against: >>>>>>>> >>>>>>>> 1. It'd suck to not be able to use 'id' as a variable name, and would >>>>>>>> conflict with a lot of existing code. >>>>>>>> 2. Alternative names to 'id' or namespacing it are not shorter than >>>>>>>> '&(&1)' >>>>>>>> 3. '&(&1)' is more open to change with requirements >>>>>>>> 4. Adopting 'id' within Kernel would encourage adding more utility >>>>>>>> functions to it, exacerbating 1, like the proposed 'filter' function >>>>>>>> 5. Not adopting it within the Kernel would be hard, as there's no >>>>>>>> real appropriate place for it elsewhere in standard lib, unlike Enum's >>>>>>>> 'filter' >>>>>>>> >>>>>>>> Generally it's a nice idea, but I can't think of a great way to make >>>>>>>> it work, and it'd open the floodgates to more utility functions that >>>>>>>> I've >>>>>>>> come to find grating in day-to-day python development. >>>>>>>> >>>>>>>> Just my two cents, >>>>>>>> Chris K >>>>>>>> >>>>>>>> -- >>>>>>>> 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 [email protected]. >>>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/d/msgid/elixir-lang-core/fffd5b76-4385-40de-93bd-148f1b94bb27%40googlegroups.com >>>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/fffd5b76-4385-40de-93bd-148f1b94bb27%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> You received this message because you are subscribed to a topic in >>>>>>>> the Google Groups "elixir-lang-core" group. >>>>>>>> To unsubscribe from this topic, visit >>>>>>>> https://groups.google.com/d/topic/elixir-lang-core/tB61BHYIH1s/unsubscribe >>>>>>>> . >>>>>>>> To unsubscribe from this group and all its topics, send an email to >>>>>>>> [email protected]. >>>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/d/msgid/elixir-lang-core/b2149582-b8ba-4759-99ac-a634f73f3243%40Spark >>>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/b2149582-b8ba-4759-99ac-a634f73f3243%40Spark?utm_medium=email&utm_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 [email protected]. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/elixir-lang-core/CAD9kT2R41gmZXU9_YAqAdyJQDP-M37j-mgUet-okoeBzF%3DdMDA%40mail.gmail.com >>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/CAD9kT2R41gmZXU9_YAqAdyJQDP-M37j-mgUet-okoeBzF%3DdMDA%40mail.gmail.com?utm_medium=email&utm_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 [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/elixir-lang-core/2bb429a8-e583-48c1-a335-8660c115b24f%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/elixir-lang-core/2bb429a8-e583-48c1-a335-8660c115b24f%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- >>>> >>>> Andrea Leopardi >>>> [email protected] >>>> >>>> -- >>>> 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 [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/elixir-lang-core/CAM9Rf%2BJEN7vuwxxZFkrB8NytCCaSPAKtroMeA1sqe91n5SoFXg%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/elixir-lang-core/CAM9Rf%2BJEN7vuwxxZFkrB8NytCCaSPAKtroMeA1sqe91n5SoFXg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> -- >>> >>> Regards, >>> Bruce Tate >>> CEO >>> >>> >>> <https://bowtie.mailbutler.io/tracking/hit/f8218219-d2a8-4de4-9fef-1cdde6e723f6/c7c97460-016e-45fb-a4ab-0a70318c7b97> >>> >>> Groxio, LLC. >>> 512.799.9366 >>> [email protected] >>> grox.io >>> >>> -- >>> 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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/elixir-lang-core/CAFXvW-65ztTOMoVhZ407PghmYA0OBcuVhDatcjYx6Xw7f52pMQ%40mail.gmail.com >>> <https://groups.google.com/d/msgid/elixir-lang-core/CAFXvW-65ztTOMoVhZ407PghmYA0OBcuVhDatcjYx6Xw7f52pMQ%40mail.gmail.com?utm_medium=email&utm_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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/elixir-lang-core/702CFF39-BCFF-416F-BF28-81A5E1516903%40chrismccord.com >>> <https://groups.google.com/d/msgid/elixir-lang-core/702CFF39-BCFF-416F-BF28-81A5E1516903%40chrismccord.com?utm_medium=email&utm_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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/20190731104042.1b6a2fb4.eksperimental%40autistici.org.
-- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/0102A584-0AB3-453E-9AA4-91E5B79FEEF5%40gmail.com.
