Oh, I well appreciate that making it easy to express these things as functions opens up a lot of other things that can be built through function composition and similar very FP-ish patterns. It's just that it also plays into the pattern I've seen in the code of people coming from imperative to functional programming of just wanting to set fields in records without really thinking of the record as a whole and the consequences for that field assignment. Functional programming gains some of its strength by getting programmers to break free of thinking in terms of assignments by removing that tool. I worry that making it too easy to do something like an assignment is just asking for people to slide into patterns that undermine the benefits of FP. That said, I would often love to have this syntax.
Mark On Sun, Aug 28, 2016 at 9:51 PM, Joey Eremondi <[email protected]> wrote: > treating the fields in a record like this tends to encourage imperative >> thinking > > > On the contrary, turning this into a function, that can be passed around, > composed, and such, is in some sense, the essence of functional thinking. > > This could have great advantages for accessing deep within nested > structures, dealing with Maybes in nested records, etc. It's just a > function, which you can use "map" or << or any other wonderful functional > tools that make Elm useful. > > It's also worth mentioning also that functions like this are well studied > in Haskell, and give way to things like Lenses. So having these isn't > frowned upon in the functional community in general. > > On Sun, Aug 28, 2016 at 9:46 PM, Mark Hamburg <[email protected]> > wrote: > >> The Elm equivalent if it existed would probably be: >> >> .name= : String -> Person -> Person >> >> >> I have certainly written plenty of code where I would have appreciated >> this but I do also worry that treating the fields in a record like this >> tends to encourage imperative thinking and discourage thinking about the >> validity of the record as a whole. >> >> Mark >> >> On Sun, Aug 28, 2016 at 4:32 PM, John Mayer <[email protected]> wrote: >> >>> For the purpose of comparison, this reminds me of a feature of case >>> classes in Scala. Case classes are somewhat similar to records in that they >>> can be succinctly defined as just some named fields. By default, they have >>> a copy method which each field can be provided optionally and override the >>> value of the input. >>> >>> One cool idea would be to have a sort of copy keyword which takes two >>> records where one is a field-unifiable-subset of the other. However this >>> probably can't be defined generally in plain Elm because the type system >>> doesn't support this notion of subsets. >>> >>> Maybe you could write a preprocessor which expanded the keyword into a >>> lambda by inspecting the input and update records. This approach could even >>> delegate the type checking to the type checker and just rely on the syntax >>> tree. >>> >>> You could write a code generator which created methods which act like >>> copy, one for each field, or one big one where each field was a Maybe type. >>> >>> On Aug 28, 2016 6:50 PM, "Joey Eremondi" <[email protected]> >>> wrote: >>> >>>> There have been requests for this before. I personally think they'd be >>>> great, but there's not a current way to do it other than lambda. >>>> On Aug 28, 2016 2:42 PM, "Esad Hajdarevic" <[email protected]> wrote: >>>> >>>>> Hi, >>>>> >>>>> with the current Elm syntax, is there a way to partially apply a >>>>> record update? Something like >>>>> >>>>> type alias Person = { name: String, age: Int } >>>>> >>>>> p = { name: "Joe", age: 32 } >>>>> >>>>> p.name= :: String -> Person >>>>> >>>>> or >>>>> >>>>> { p | name = } :: String -> Person >>>>> >>>>> or even >>>>> >>>>> { p | name =, age = 30} :: String -> Person >>>>> >>>>> I'm asking because I'd like to update a record in a pipeline. Wrapping >>>>> in a lambda \x -> { p | name = x } works, but I was wondering if there >>>>> could be a more compact way of doing this. >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Elm Discuss" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Elm Discuss" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Elm Discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Elm Discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "Elm Discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
