4 ms·

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 Hask

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?

joelwilliamson 12y ago
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.
- wcbeard10 12y ago
  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.
  - jozefg 12y ago
    It does, it's ambiguous to have `Constructor.fun` for this reason.
  - deleted 12y ago
    [deleted]
- yummyfajitas 12y ago
  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.
  - chongli 12y ago
    Yes and Haskell allows arbitrary user-defined operators. Once the genie is out of that bottle it's hard to put it back inside!
gregwebs 12y ago
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).
- mercurial 12y ago
  > This has been proposed, and it is still a good idea if one wants to make Haskell accessible to OO programers. That's how OCaml records work, too.
- FreeFull 12y ago
  The . already has whitespace-sensitive use for namespacing in Haskell, for example `Data.List.concat` is parsed differently from `Data . List . concat`
- njs12345 12y ago
  Here's the Trac page of the proposal: https://ghc.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution https://ghc.haskell.org/trac/haskell-prime/wiki/TypeDirected... Also a bit disappointed that it didn't make the cut - it seemed like a good pragmatic solution!
tel 12y ago
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.
- yummyfajitas 12y ago
  In many cases a concrete type can be inferred: map (\x -> x.slot) listOfFoos Pretty sure that x has type `Foo` in this case. 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.
  - dllthomas 12y ago
    "(pretty sure it can never appear in the range)" Wouldn't update do that? Making up further syntax... (\x -> prototype.slot = x) :: HasField "slot" b a => b -> a Or am I missing what you meant by "appear in the range"?
  - tel 12y ago
    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.
    - yummyfajitas 12y ago
      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.

joelwilliamson 12y ago

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.

wcbeard10 12y ago
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.
- jozefg 12y ago
  It does, it's ambiguous to have `Constructor.fun` for this reason.
- deleted 12y ago
  [deleted]
yummyfajitas 12y ago
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.
- chongli 12y ago
  Yes and Haskell allows arbitrary user-defined operators. Once the genie is out of that bottle it's hard to put it back inside!

gregwebs 12y ago

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).

mercurial 12y ago
> This has been proposed, and it is still a good idea if one wants to make Haskell accessible to OO programers. That's how OCaml records work, too.
FreeFull 12y ago
The . already has whitespace-sensitive use for namespacing in Haskell, for example `Data.List.concat` is parsed differently from `Data . List . concat`
njs12345 12y ago
Here's the Trac page of the proposal: https://ghc.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution https://ghc.haskell.org/trac/haskell-prime/wiki/TypeDirected... Also a bit disappointed that it didn't make the cut - it seemed like a good pragmatic solution!

tel 12y ago

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.

yummyfajitas 12y ago
In many cases a concrete type can be inferred: map (\x -> x.slot) listOfFoos Pretty sure that x has type `Foo` in this case. 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.
- dllthomas 12y ago
  "(pretty sure it can never appear in the range)" Wouldn't update do that? Making up further syntax... (\x -> prototype.slot = x) :: HasField "slot" b a => b -> a Or am I missing what you meant by "appear in the range"?
- tel 12y ago
  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.
  - yummyfajitas 12y ago
    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.