Can you give more details about an example of where doing nested record
updates is useful? When I've run into nested records in real projects,
usually it's a better choice to remove the nested update. Here are two
ways to do that:
1) flatten the record
This is appropriate when a single module is dealing with a bunch of things
that don't actually need to be nested:
Instead of this:
type alias Course =
{ teacher : { id : Int, name : String } }
Try this:
type alias Course =
{ teacherId : Int
, teacherName : String
}
2) make the nested thing into a module
This is appropriate when it makes sense to have functions that manipulate
the nested thing.
Instead of this:
moveSpaceshipEast ship =
let
oldPosition = ship.position
newPosition = { oldPosition | x = oldPosition.x + 1 }
in
{ ship | position = newPosition }
Try this:
moveSpaceshipEast ship =
{ ship | position = Position.addX 1 ship.position }
module Position
addX dx position =
{ position | x = position.x + dx }
On Sun, Aug 14, 2016 at 11:28 AM, OvermindDL1 <[email protected]> wrote:
>
> Lists/Dicts/Records do have different interfaces, however if Elm had HKT's
> it would not need to, you could have a generic 'map' function that works
> over all of them, a generic fold, etc... and so forth (See Haskell).
>
> However note the List Access is what would define the required structure
> of the thing that would be passed in, that is resolvable in the type system
> quite easily (at least with HKT's, unsure otherwise).
>
> However, ignoring other types and just doing it for records you could do
> it with the current Elm type system 'if' we get some kind of way to set a
> record value via an argument, I.E. we could create all the proposed
> getters/setters 'now' on just records if we get a function that acts
> something like:
> ```elm
> Record.set : RecordID record id -> id_type -> { record | id : id_type }
> Record.set id val rec = <something perhaps like `{ rec | id=val }`>
> ```
> That allows type-safe enforcement of a key ID.
> Where you could use it like:
> ```elm
> model = { something=0 }
> newModel = Record.set 42 model
> newModel == { something=42 }
> ```
> Basically Elm needs something like Ocaml's Field(s) functions:
> ```ocaml
> Field.t # Type declaration for following inputs/outputs
> Field.name # Get the name of a record field
> Field.get # Get the value of a record field
> Field.fset # Functionally set the value of a record field, returning the
> new record with the new field value
> ```
> Which can be used like (remember Ocaml's type system is exceedingly strict
> with no HKT support, it's type system is not as advanced as, say,
> Haskell's):
> ```ocaml
> module Model = struct
> type t =
> { something : int
> };;
> end
> module Model :
> sig
> type t =
> { something : int;
> }
> end
>
> let model = { Model.
> something = 42;
> };;
>
> let name = Field.name Model.Fields.something model;; # Returns a string of
> "something"
>
> let val = Field.get Model.Fields.something model;; # Returns an int of 42
>
> let newModel = Field.fset Model.Fields.something 3 model # Returns the
> structure of { something = 3 }
> ```
>
> So yes it is very possible in the normal Elm type system as Ocaml's is
> similarly restricted. As I recall Ocaml is using the functional idiom
> called Lenses in its field work to do that (lot of packaging access up in
> functions, but does require a record to have more data, like adding an
> implicit RecordName.Fields thing or so, or make better syntax for it).
>
> With proper HKT's, like with Haskell, then fully type-safe we could have
> very powerful, generic, and simple syntax such as this:
> ```haskell
> -- Given these simplified types:
> data Model = Model { something :: SomeSubData }
>
> data SomeSubData = SomeSubData { moreThing :: Integer }
>
> -- And given this value
> where
> model = Model (SomeSubData 42)
>
>
> -- You could do the way that Elm does now (although elm has the existing
> record inside the {} and haskell has it outside, so this is how haskell
> does it):
> newModel = model {
> something = (something model) {
> moreThing = moreThing (something model) + 1
> }
> }
>
>
> -- The above set newModel as { something = { moreThing = 43 } } in Elmish
> parlance, and is very similar to how it is done in Elm itself, however
> Haskell has HKT's, which allow for a variety of other methods such as:
>
>
> -- references+lenses (not possible to do anything even remotely like this
> in Elm right now due to not being able to operate over types, but it is the
> most succinct):
> $(mkLabels [ 'Model, 'SomeSubData ]) -- Only need to do this once
>
> newModel = modify (+1) (moreThing . something) model
>
>
> -- SYB (A generic library that handles tasks like this with is, it comes
> bundled with Haskell
> incMoreThing v s@(SomeSubData moreThing) = s { moreThing = moreThing + v
> } -- Per change you want to make anywhere in the record path
>
> newModel = everywhere (mkT (incMoreThing 1))
>
>
> -- Semantic Editor Combinators (low-level version of SYB, no libraries
> needed, and you could make these 'now' in Elm, and I have to an extent, but
> it is very easy in haskell to define it from scratch, as doing here, still
> very wordy as it requires one function made per key):
> type SemEdit a = a -> a
> type Lifter p q = SemEdit p -> SemEdit q
>
> onSomething :: Lifter SomeSubData Model
> onSomething f (Model something) = Model (f something)
>
> onMoreThing :: Lifter Integer SomeSubData
> onMoreThing f (SomeSubData moreThing) = SomeSubData
>
> newModel = (onSomething . onMoreThing) (+1) model
> ```
>
> So yes, it is very possible to perform such things while remaining
> strongly typed. OCaml does it with an interface similar to my first
> email. Haskell can do it with ease in an almost crazy amount of ways and
> would be the better ways by far, however most of its ways require HKT's
> and/or code that works on types. My original email proposal for just the
> records is something that could be added to Elm with relative ease now
> compared to enhancing the entire type system with HKT's.
>
> More responses in-line. :-)
>
>
> On Sunday, August 14, 2016 at 10:54:15 AM UTC-6, Joey Eremondi wrote:
>>
>> Also, Lists, Dicts, and Records have different interfaces *because they
>> are fundamentally different*
>>
>
> Yes, that was an example and it would be most useful for nested records.
> I was showing that example as a 'complete' method that could work over
> everything as the API.
>
>
> On Sunday, August 14, 2016 at 10:54:15 AM UTC-6, Joey Eremondi wrote:
>
>> If you are accessing the nth element of a List so often that you need
>> special syntax to do so, you are doing something wrong, because list's are
>> intended for iteration. You probably want an array.
>>
>
> Normally you'd never ever do that, usually you would use Access.all for
> lists, which does indeed iterate over all of them (even nested records
> instead nested records instead a list that is inside a record would be
> trivial via `[ :something, Access.all, :anotherkey, :yetanotherkey ]`),
> just showing it for completion.
>
>
> On Sunday, August 14, 2016 at 10:54:15 AM UTC-6, Joey Eremondi wrote:
>
>> Likewise, if you ever have a time where, at compile-time, you're trying
>> to access a field in a record that might not exist, you're doing something
>> terribly wrong, since that's not what records are for.
>>
>
> Such code in typed languages would indeed create a compile-time error.
> Things like variables that are only known at run-time are not allowed in
> the keylist, only constants or sub-types that restrict the value of keys
> allowed to the given record are allowed and is type-safe.
>
>
> On Sunday, August 14, 2016 at 10:54:15 AM UTC-6, Joey Eremondi wrote:
>
>> I can see why these things look nice coming from Elixr, but Elm is not
>> Elixr. We choose types, and there is a degree of awkwardness that comes
>> from this, and that is somewhat inherent to the system. These things are
>> easy when you have no types, like Elixr, and they are hard when you have
>> types, in Elm. There is tons of research going on into how to deal with
>> these things in a typed setting, but that's how you get the hundreds of GHC
>> extensions like Haskell has, most of which break type inference and require
>> you to annotate things yourself.
>>
>
> This is not purely an Elixir thing, I just used it as is was a more simple
> example compared to the complete and type-safe and OCaml code, which I gave
> a hint of above (with the `Field(s)` stuff).
>
>
> On Sunday, August 14, 2016 at 10:54:15 AM UTC-6, Joey Eremondi wrote:
>
>> On Sun, Aug 14, 2016 at 9:47 AM, Joey Eremondi <[email protected]>
>> wrote:
>>
>>> @OvermindDL1: I'm still grokking what you've proposed, but it's
>>> problematic for a few reasons. I'm 99% sure that it can't be done in a way
>>> that is type safe.
>>>
>>
> It can, because OCaml does. If we get a better type system sometime in
> Elm then we could use even the better patterns that we do use in Haskell.
>
>
> On Sunday, August 14, 2016 at 10:54:15 AM UTC-6, Joey Eremondi wrote:
>
>> What you're doing doesn't need Higher-Kinded types, it's just not type
>>> safe, at least not as how it's presented here.
>>>
>>> One is that you've got type variables in your Access type that it is not
>>> parameterized over. So you need to do something like this:
>>>
>>> type Access recordKeyType dictKeyType
>>> = All
>>> | At Int
>>> | Elem Int
>>> | Key recordKeyType {- Whatever recordKeyType might be as an indicator
>>> for a key on a record -}
>>> | DictKey dictKeyType
>>> | Fn (EnumerableType -> EnumerableType) {- This is why I think HKT's
>>> might be needed, or special caseing in the compiler -}
>>>
>>> or, with Higher-Ranked Types
>>>
>>> type Access
>>> = All
>>> | At Int
>>> | Elem Int
>>> | Key (forall recordKeyType . recordKeyType) {- Whatever recordKeyType
>>> might be as an indicator for a key on a record -}
>>> | DictKey (forall dictKeyType . dictKeyType)
>>> | Fn (EnumerableType -> EnumerableType) {- This is why I think HKT's
>>> might be needed, or special caseing in the compiler -}
>>>
>>> but, I'm pretty sure neither of these would do what you want. In the
>>> first case, you'd need to know ahead of time what kind of record or Dict
>>> you were dealing with, or you'd need to write something that worked with
>>> any record/dict type, which is probably too generic to get anything done.
>>>
>>
> It was a quick write-up, not meant as a final API as I am asking about
> ideas of the style, not of my specific implementation. ;-)
>
>
> On Sunday, August 14, 2016 at 10:54:15 AM UTC-6, Joey Eremondi wrote:
>
>> In the second case, you'd have to give a value that is *truly* generic,
>>> that matches literally any type you throw at it. There is no such value.
>>> This is also problematic, since it causes all sorts of awful with type
>>> inference and would require significantly changing Elm's type system.
>>>
>>
> No, rather the types should be compared recursively through value types
> specified in the list, it definitely would *not* work as presented, nor was
> it meant to be, just given as a possible example of usage.
>
>
> On Sunday, August 14, 2016 at 10:54:15 AM UTC-6, Joey Eremondi wrote:
>
>> Also, I don't think you're quite understanding how the type variables
>>> work. Let's look at the signature here:
>>>
>>> {-| Sets a value(s) at the given path -}
>>> putIn
>>> : List Access
>>> -> newValue
>>> -> EnumerableType
>>> -> EnumerableType
>>>
>>> Every type variable in Elm has an implicit "forall" at the beginning of
>>> the signature. So this is really:
>>>
>>> {-| Sets a value(s) at the given path -}
>>> putIn
>>> : forall newValue . List Access
>>> -> newValue
>>> -> EnumerableType
>>> -> EnumerableType
>>>
>>> so what you're saying is, for *literally any type* T, if you give me a
>>> List of Access and a value of type T and an EnumerableType, I can give you
>>> an updated EnumerableType. So all of the following would be allowed:
>>>
>>> putIn [At 3] "Hello" {field = False}
>>> putIn [Key foo] "Hello" {foo = True}
>>> putIn [Key foo] "Hello" {bar ="Goodbye"}
>>>
>>> All of these should generate type errors, but they wouldn't with the
>>> given types you have.
>>>
>>
> Correct, but as stated, it is not an implementation example, just an idea
> for a way of editing records, not a defined API, such a thing could be made
> later if so wished, instead of a list of accesses you could have curried
> functions (that would even work as-is in elm right now, but would require a
> *lot* of boilerplate that elm should be able to generate itself as it knows
> the record types).
>
>
> On Sunday, August 14, 2016 at 10:54:15 AM UTC-6, Joey Eremondi wrote:
>
>> On Sun, Aug 14, 2016 at 8:40 AM, OvermindDL1 <[email protected]> wrote:
>>>
>>>> Expressions are not currently allowed to be updated like that, so would
>>>> that return a model with the something.more updated on it (seems
>>>> surprising) or return model.something with more updated on it (not
>>>> surprising, and would allow arbitrary expressions there).
>>>>
>>>>
>>>>
>>>> On Saturday, August 13, 2016 at 11:51:29 PM UTC-6, Robin Heggelund
>>>> Hansen wrote:
>>>>>
>>>>> All I really want is:
>>>>>
>>>>> ```elm
>>>>> { model.something | more = 42 }
>>>>> ```
>>>>>
>>>>> søndag 14. august 2016 02.49.07 UTC+2 skrev OvermindDL1 følgende:
>>>>>>
>>>>>> Just a passing idea to perhaps help give ideas for better methods:
>>>>>>
>>>>>>
>>>>>> Updating a nested record is a bit convoluted as something like:
>>>>>> ```elm
>>>>>> let
>>>>>> something = model.something
>>>>>> in
>>>>>> { model | something = { something | more = 42 } }
>>>>>> ```
>>>>>> Excepting the let/in part because Elm does not support an expression
>>>>>> as the first argument (`model` and `something` in these cases) for
>>>>>> I-have-no-clue-reason, and another language I work often in is Elixir,
>>>>>> its
>>>>>> syntax for the above would be similar:
>>>>>> ```elixir
>>>>>> %{ model | something: %{ model.something | more: 42 } }
>>>>>> ```
>>>>>>
>>>>>> However, that is painful, so Elixir has a couple of helper functions
>>>>>> that simplify that kind of work, let me demonstrate, this does the same
>>>>>> as
>>>>>> the above:
>>>>>> ```elixir
>>>>>> put_in models, [:something, :more], 42
>>>>>> ```
>>>>>> And you can go arbitrarily deep and it returns a new model with the
>>>>>> path altered to the given value as necessary. Elixir also has lispy
>>>>>> macros
>>>>>> so you can also use the above function via:
>>>>>> ```elixir
>>>>>> put_in models.something.more, 42
>>>>>> ```
>>>>>> Basically using 'read' syntax to specify the path, but it gets
>>>>>> expanded to the above at compile-time. It also supports not only records
>>>>>> but also maps (dicts in elm), lists (also lists in elm) and anything else
>>>>>> that follows the Access protocol (a set of functions of certain types to
>>>>>> do
>>>>>> basic functions), but those are the default.
>>>>>>
>>>>>> It has extra features like this, say `model.something` is a `List
>>>>>> Int` in elm parlance:
>>>>>> ```elixir
>>>>>> put_in model, [:something, Access.all], 42
>>>>>> ```
>>>>>> This will set any and all values in the list at model.something to
>>>>>> 42, not terribly useful, however it has a lot more functions as well,
>>>>>> such
>>>>>> as (I want to use more 'elmy' syntax, so I will now use things like
>>>>>> `.something` instead of `:something` and no commas between arguments,
>>>>>> only
>>>>>> in tuples and lists and such):
>>>>>> ```elixir
>>>>>> -- Where model = { something : Dict String (List Int) }
>>>>>> ( oldValue, newModel ) = get_and_update_in model [ .something, "joe",
>>>>>> Access.at(0) ] (\oldValue -> let oldValue = Maybe.withDefault 0 in (
>>>>>> oldValue, Just (oldValue+1) ))
>>>>>> ```
>>>>>> This will update a value in and let you return a value (anything you
>>>>>> wish) within a tuple. This one will access `Dict.get "joe"
>>>>>> model.something` and get the returned list, accessing the first element
>>>>>> (`at` for lists, `elem` for a tuple index starting at 0 as well), and the
>>>>>> called passed in function returns a tuple where the first element is the
>>>>>> first element of the returned tuple and the second element is what the
>>>>>> thing at the path will be updated to, so this case will return the
>>>>>> `oldValue+1` if it existed, if it did not then it returns 1 due to the
>>>>>> `withDefault 0`.
>>>>>>
>>>>>> More functions it adds are:
>>>>>> ```elixir
>>>>>> -- Where model = { something : Dict String (List Int) }
>>>>>> value = get_in model [ .something, "joe", Access.at(2) ] -- Returns
>>>>>> the value at the path
>>>>>>
>>>>>> values = get_in model [ .something, Access.all, Access.at(2) ] --
>>>>>> Returns all of the values 2nd values in the lists in all the values of
>>>>>> the
>>>>>> dictionary as a list if they exist, else they are skipped
>>>>>>
>>>>>> pop_in model [ .something, Access.all, Access.at(2) ] -- Removes the
>>>>>> element in the list at position 2 in all the dictionary values if it
>>>>>> exists, if it does not exist then it skips it
>>>>>>
>>>>>> update_in model [ .something, Access.all, Access.at(2) ] (\oldValue
>>>>>> -> Just (( oldValue |> Maybe.withDefault 0 ) + 4)) -- Updates a value(s)
>>>>>> in-place
>>>>>> ```
>>>>>> Along with macro's for the read-format pathing, which is not needed
>>>>>> here.
>>>>>>
>>>>>> The keylist (the `[ .something, Access.all, Access.at(2) ]` in the
>>>>>> last example) can also take functions, whatever they return (empty list,
>>>>>> single-element list, multiple-element list, etc...) will be what is used
>>>>>> and what is set back.
>>>>>>
>>>>>>
>>>>>> *Thus*, what would be thought of Elm adding in functions like these
>>>>>> (HKT's might be needed, not thought through the implementation yet, only
>>>>>> the API):
>>>>>> ```
>>>>>> type Access
>>>>>> = All
>>>>>> | At Int
>>>>>> | Elem Int
>>>>>> | Key recordKeyType {- Whatever recordKeyType might be as an
>>>>>> indicator for a key on a record -}
>>>>>> | DictKey dictKeyType
>>>>>> | Fn (EnumerableType -> EnumerableType) {- This is why I think
>>>>>> HKT's might be needed, or special caseing in the compiler -}
>>>>>>
>>>>>> -- You'd need some kind of EnumerableType as well, no doubt opaque
>>>>>> or something, or need HKT's, probably need HKT's in general, Elm really
>>>>>> badly needs HKT's...
>>>>>>
>>>>>> {-| Get a value calculated from the old value and set a new value
>>>>>> simultaneously -}
>>>>>> getAndUpdateIn
>>>>>> : List Access
>>>>>> -> (Maybe valueType -> ( retValue, Maybe valueType ))
>>>>>> -> EnumerableType
>>>>>> -> ( List retValue, EnumerableType )
>>>>>>
>>>>>>
>>>>>> {-| Gets a value from an access path -}
>>>>>> getIn
>>>>>> : List Access
>>>>>> -> EnumerableType
>>>>>> -> List retValue
>>>>>>
>>>>>>
>>>>>> {-| Removes a value from a given path if possible, returning it if it
>>>>>> exists -}
>>>>>> popIn
>>>>>> : List Access
>>>>>> -> EnumerableType
>>>>>> -> ( List retValue, EnumerableType )
>>>>>>
>>>>>>
>>>>>> {-| Sets a value(s) at the given path -}
>>>>>> putIn
>>>>>> : List Access
>>>>>> -> newValue
>>>>>> -> EnumerableType
>>>>>> -> EnumerableType
>>>>>>
>>>>>>
>>>>>> {-| Updates a value in the path and returns the new modified object -}
>>>>>> updateIn
>>>>>> : List Access
>>>>>> -> (Maybe oldValue -> Maybe newValue )
>>>>>> -> EnumerableType
>>>>>> -> EnumerableType
>>>>>> ```
>>>>>>
>>>>>> These could then be used like:
>>>>>> ```
>>>>>> -- Where model = { something : Dict String (List Int) }
>>>>>> -- With values of: model = { something = Dict.fromList [("joe", [1,
>>>>>> 2, 3]), ("beth", [10, 11, 12, 13])] }
>>>>>>
>>>>>>
>>>>>> ( oldValue, newModel ) = model |> getAndUpdateIn [ Key .something,
>>>>>> DictKey "joe", All] (\v -> ( v, v |> Maybe.withDefault 0 |> (+) 1 ))
>>>>>> -- Will return `oldValue == 1`
>>>>>> -- And returns `newModel == { something = Dict.fromList [("joe", [2,
>>>>>> 2, 3]), ("beth", [10, 11, 12, 13])] }`
>>>>>>
>>>>>>
>>>>>> newModel = model |> putIn [ Key .something, All ] [ 42 ]
>>>>>> -- Will return `newModel == { something = Dict.fromList [("joe",
>>>>>> [42]), ("beth", [42])] }````
>>>>>>
>>>>>>
>>>>>> newModel = model |> updateIn [ Key .something, Fn (\dict -> dict |>
>>>>>> Dict.filter (\k v -> (String.length k) >= 4 ) ) ] (\v -> v)
>>>>>> -- Will return `newModel == { something = Dict.fromList [("beth",
>>>>>> [10, 11, 12, 13])] }`
>>>>>> -- This is because we used a Fn to return the set of things we want
>>>>>> to operate over and as such will only assign those back, allowing us to
>>>>>> filter out things with ease.
>>>>>> ```
>>>>>>
>>>>>> This style makes doing very complex embedded enumerable updating with
>>>>>> ease. However as the above is proposed it would likely require Higher
>>>>>> Kind
>>>>>> Types in Elm, which does not have those yet, thus for now just
>>>>>> implementing
>>>>>> the above for just records would be sufficient for a good portion if not
>>>>>> the overwhelming majority of program, and that could be done without
>>>>>> HKT's.
>>>>>>
>>>>> --
>>>> 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.
