2012/1/8 Ingo Wechsung
2012/1/8 Gábor Lehel
The second is that only the author of the datatype could put functions into its namespace; the 'data.foo' notation would only be available for functions written by the datatype's author, while for every other function you would have to use 'foo data'. I dislike this special treatment in OO languages and I dislike it here.
Please allow me to clarify as far as Frege is concerned. In Frege, this is not so, because implementations of class functions in an instance will be linked back to the instantiated types name space. Hence one could do the following:
module RExtension where
import original.M(R) -- access the R record defined in module original.M
class Rextension1 r where firstNewFunction :: ..... secondNewFunction :: .....
instance Rextension1 R where -- implementation for new functions
And now, in another module one could
import RExtension() -- equivalent to qualified import in Haskell
and, voilá, the new functions are accessible (only) through R
Ah, I see. And that answers my other question as well about why you would special case class methods like this. Thanks. I think I prefer Disciple's approach of introducing a new keyword alongside 'class' to distinguish 'virtual record fields' (which get put in the namespace) from any old class methods (which don't). Otherwise the two ideas seem very similar. (While at the same time I still dislike the wrong-direction aspect of both.) It strikes me that this kind of 'virtual record fields' (or 'projectors') thing is trying to tackle a very similar problem space as views and view patterns do. Namely, a kind of implementation hiding, eliding the difference between information which happens to represented by actual physical data and information which is merely calculated from that data. So you could in theory later change the representation (which fields are stored and which are calculated) without the client code noticing. There also seems to be an analogy between view patterns and simple function-based virtual-record-fields on the one hand, which are read-only, and full views and a theoretical lens-based virtual-record-fields on the other hand, which you can also use for update. (I don't see any way around having to write both the access and update function manually though, unless someone figures out how to invert functions in the general case). I don't have any follow-on thoughts from this at the moment but it seemed interesting to note.
-- Mit freundlichen Grüßen Ingo
-- Work is punishment for failing to procrastinate effectively.