Dot notation for "Methods"

[Anderssorby]

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

[github-actions]

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.

[lucamug]

Some discussion here: https://discourse.elm-lang.org/t/dot-notation-for-methods/8727

[turboMaCk]

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)