[Haskell-cafe] I'm afraid of OverloadedLabels.

[Nikita Churaev]

> AND PLEASE not the way an [existing proposal] suggests to do
> it!  Please
> let's just do ad-hoc overloading.  There is no reason to introduce
> new
> syntax, because syntax is completely orthogonal to this problem.

I think that a new syntax is needed though. Here's my reasoning:

Why do mainstream OOP languages have it so easy, while Haskell hasn't
been able to solve the name collision problem for many, many years?

I think one of the obstacles is that currying has encouraged most
libraries to put any object arguments last, eg:

    insert :: Int -> a -> [a] -> [a]
    insert :: a -> Set a -> Set a
    insert :: k -> v -> Map k v -> Map k v

instead of putting it first (like in most OOP languages):

    insert :: [a] -> Int -> a -> [a]
    insert :: Set a -> a -> Set a
    insert :: Map k v -> k -> v -> Map k v

I think this is precisely the reason why OOP languages have it easy
while Haskell is struggling.

If the significant argument is predictably first, TNDR is super-easy to
implement even in current Haskell, if you are willing to create a class
for every single method:

    {-# LANGUAGE FunctionalDependencies #-}
    {-# LANGUAGE FlexibleInstances #-}

    import Data.Set (Set)
    import Data.Map (Map)
    import qualified Data.Set as Set
    import qualified Data.Map as Map

    class Insert a f | a -> f where
        insert :: a -> f

    instance Insert [a] (Int -> a -> [a]) where
        insert list at item = take at list ++ [item] ++ drop at list

    instance Ord a => Insert (Set a) (a -> Set a) where
        insert set item = Set.insert item set

    instance Ord k => Insert (Map k v) (k -> v -> Map k v) where
        insert map k v = Map.insert k v map

    main = do
        print (insert [1, 3, 4] 1 2)
        print (insert Set.empty "hello")
        print (insert Map.empty "hello" "world")

So, a new syntax is surely needed if the TNDR implementation relies on
object arguments being the first, since $ no longer works for such
functions.

Also, I think that methods should get a namespace of their own, just
like operators. The reason is to preserve backwards compatibility
without having to create any new modules: methods can be implemented
alongside old-style functions.

Another reason:

    let name = person.name in ...

If the .name method is in a namespace of its own, the name variable
doesn't become ambiguous (with all associated problems).

I don't think it would even be necessary to introduce any ambiguity-
resolving behaviour into normal namespace if methods are in a namespace
of their own.

Methods would be defined like this:

    .insert :: Ord k => Map k v -> k -> v -> Map k v
    .insert map k v = ...

Invoked like this (just like in existing proposal):

    Map.empty .insert "hello" "world"
              .insert "cat" "meow"
              .insert "haskell" "awesome"

Currying by not applying the object:

    .insert x y :: Map k v -> Map k v

Currying by not applying the arguments:

    map .insert :: k -> v -> Map k v

Prefix application:

    (.insert) map k v