compiler
compiler copied to clipboard
elm
Dot notation for "Methods"
I think adding a function "method" dot notation would simplify expressions and ease adaptation for JS-developers. Lean4 is purely functional, but also has support for .dot notation for associated functions. https://leanprover.github.io/lean4/doc/namespaces.html I think this should be added to Elm too.
Example
type alias A =
{ b: String }
-- this is possible
getB = .b
-- A new possibility to add functions to the type "namespace"
A.doStuff : A -> B -> C
A.doStuff self b = c
-- This could also be possible
fun : A -> B -> C
fun a = a.doStuff
f : Maybe a -> b
f m = m.map (\a -> a.stuff) |> .withDefault defaultB
Thanks for reporting this! To set expectations:
- Issues are reviewed in batches, so it can take some time to get a response.
- Ask questions in a community forum. You will get an answer quicker that way!
- If you experience something similar, open a new issue. We like duplicates.
Finally, please be patient with the core team. They are trying their best with limited resources.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Some discussion here: https://discourse.elm-lang.org/t/dot-notation-for-methods/8727
I did not read the discussion on discourse so apologizes if I'm repeating something from there.
With this proposal I wonder what you would expect for this code to produce:
adding_one t =
t.map (\a -> a + 1)
My take
I can imagine primarily 2 expected results...
Ad-hoc Polymorphism
This code should compile and work so that I can call:
adding_one (Just 1)
--> Just 2
adding_one [1, 2, 3]
--> [2, 3, 4]
Anyway as you can see this introduces new type of polymorphism which is currently not possible in elm. The type would be something like:
adding_one : f Int -> f Int
where f is of kind kind f = Type -> Type
This Code should be rejected
Compiler should error with something can't specialize f in ... prohibiting you from using this feature in this way. In such case you would need to somehow specify which type does t have like:
adding_one : Maybe Int -> Maybe Int
Anyway as you can see this syntax would break type inference in a way it would no longer be possible to infer type without this annotation.
Also in my opinion this makes whole feature kind of useless. It would make . just an alternative syntax |> which is also ambiguous. This code which is already possible at the moment doesn't have this problem and provides exactly the same capabilities:
adding_one f =
f |> Maybe.map ((+) 1)
