The only problem with this is "name".
It is too easy to have naming clash in haskell. Field selectors are also
top-level functions and they shared the same namespace with other
functions.
for any reasonable scale program, we'll end up with ModuleA.read x,
ModuleB.read b. (Yes, we can alias the modules as A and B, but then we'll
have to face the module alias naming clash again)
In java/c++, we can name a method in the most meaningful and natural way we
like, rest-assured it won't have a problem just because some other
class/interface happens to use the same name for a different thing.
Plus, module, in my opinion is a logical functionality group, a quite
coarse-grained facility. not an appropriate tool to disambiguate names in a
fine-grained way.
I like the <<Lightweight Extensible Records for Haskell >> paper by Mark
Jones and Simon P. Jones. Very clean IMHO.
Not sure why it did not get implemented.
Duncan Coutts
OK, recently I posed a question about rethinking some OO idioms, and that spawned some useful discussion.
I now have a followup question.
One of the best features of OO programming is that of inheritance. It can be used to slightly alter the behavior of objects without requiring modification to existing code or breaking compatibility with existing APIs.
Closures can do this: // in C++/Java class ConfigParser { void read (String); int getFoo (String); } -- in Haskell data ConfigParser = ConfigParser { read :: String -> IO ConfigParser getFoo :: String -> Int } This is a structure of functions. The difference from C++/Java style objects is that this gives us object based polymorphism rather than class based polymorphism. Because they are Haskell closures rather than C-style functions they can hold private state by using partial application. configParser :: ConfigParser configParser = ConfigParser { read input = ... getFoo = ... } envConfigParser :: ConfigParser envConfigParser = configParser { read input = do env <- getEnvVars read configParser (substEnvVars input) } Duncan _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe This message is intended only for the addressee and may contain information that is confidential or privileged. Unauthorized use is strictly prohibited and may be unlawful. If you are not the intended recipient, or the person responsible for delivering to the intended recipient, you should not read, copy, disclose or otherwise use this message, except for the purpose of delivery to the addressee. If you have received this email in error, please delete and advise the IT Security department at ITSEC@combined.com immediately