It seems to me that most of these issues could be solved at the syntactic level simply by allowing recordval.fieldname syntax. I truly don't understand why Haskell doesn't allow this - anyone have some insight?
This has been proposed, and it is still a good idea if one wants to make Haskell accessible to OO programers. It would require the function composition dot to have spaces around it, which is already fairly standard practice.
However, just adding some syntax does not finish solving the problem: one still needs to figure out how to get everything to typecheck under all use cases (and all type extensions) and also to operate efficiently at runtime. This article does that (although it isn't actually explained that well in the article).
The . already has whitespace-sensitive use for namespacing in Haskell, for example `Data.List.concat` is parsed differently from `Data . List . concat`
Then what is the type of (\x -> x.slot). It would have to be something like `HasField "slot" b a => a -> b` which is a significant increase in complexiy. It's not just a syntactic issue.
Nice record variants which completely solve this issue at the library level, IMO, exist. But the types are more complex than what most people want to deal with in practice.
One could then simply disallow the use of `HasField "slot" b a` in the domain of functions (pretty sure it can never appear in the range). This would then require the programmer to provide annotations if a more concrete type can't be inferred.
It can appear in the range (making up assignment syntax here)
foo :: (Num a, HasField "slot" a b) => b -> b
foo x = x.slot <~ 1
Technically, depending upon the semantics of records (how anonymous they are) it could even be that the input argument has a different type as the output argument, e.g.
foo {} ==> {slot = 1}
Anyway, there's a lot to be said here but I think that this isn't merely a syntactic difference. Even the idea that
map (\x -> x.slot) listOfFoos
could be inferred would require mixing type inference and syntax de-sugaring.
Should have said "if it can't appear in the domain, it can't appear in the range". Obviously if it appears in the domain it can also get into the range - a simpler example with real syntax is \x -> x.
What I'm arguing is that anonymous records are unnecessary and it's silly to insist that problems with anonymous records should derail a good solution for concrete ones. But you are right that it's a bit more than just syntactic.
recordval.fieldname would have the same syntax as function composition func1.func2
Since you should know the type of the first argument to '.', it is possible to disambiguate, but it would be a pretty significant corner case in the grammar.
One could simply choose an alternate symbol, e.g. record~>fieldname (which is similar to C++). I admit choosing a symbol in Haskell is a bit harder, since most of the easy ones are already taken.
That was my intuition as well, but doesn't seem to explain why we can still use the syntax with modules (i.e., Set.map), unless the capitalized module name makes all the difference.
