RE: [Haskell] Per-type function namespaces (was: Data.Set whishes)
| So there is no sub-typing, no row polymorphism, no attempt to give | f r = r.x | a fancy type that makes f applicable to any record with an x field. | | On the other hand, there is also no problem with many records having the | same field name either, which is the problem we started with. There are | no implicitly-defined record selectors either: you have to use pattern | matching for that. Andreas says: | Actually, #l is just syntactic sugar for (\{l=x,...}->x), which implies | that you might need type annotations. Yes I was wrong to say that there are no implicitly-defined record selectors; (#l r) is exactly that. Syntactically I'd prefer (r.l); but regardless, it's a syntactic construct distinct from function application, which must be monomorphic. Yes, that's a kind of interaction between binding and type system (of the kind I objected to) but a very weak and well-behaved kind of interaction. Simon
Simon Peyton-Jones wrote:
| Actually, #l is just syntactic sugar for (\{l=x,...}->x), which implies | that you might need type annotations.
Yes I was wrong to say that there are no implicitly-defined record selectors; (#l r) is exactly that. Syntactically I'd prefer (r.l); but regardless, it's a syntactic construct distinct from function application, which must be monomorphic.
I'm not sure I parsed your sentence correctly, but in SML, (#l r) indeed *is* a function application, and #l is a perfectly normal function, as its desugared form reveals. It just fails to have a principal type (due to the lack of row polymorphism), so its type must be derivable from context - which might involve a type annotation. BTW, I'd prefer r.l as well. A section like (.l) could then give you the equivalent of #l. - Andreas -- Andreas Rossberg, rossberg@ps.uni-sb.de Let's get rid of those possible thingies! -- TB
participants (2)
-
Andreas Rossberg -
Simon Peyton-Jones