5 ms·

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 n

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

by tel 12y ago

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.