[Haskell-cafe] OO idioms redux

[Ben.Yu at combined.com]

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                                                                                                              
                      <duncan.coutts at worcester.ox        To:       John Goerzen <jgoerzen at complete.org>                                          
                      ford.ac.uk>                        cc:       haskell-cafe at haskell.org                                                      
                      Sent by:                           Subject:  Re: [Haskell-cafe] OO idioms redux                                            
                      haskell-cafe-bounces at haskel                                                                                                
                      l.org                                                                                                                      
                                                                                                                                                 
                                                                                                                                                 
                      10/13/2004 08:15 AM                                                                                                        
                                                                                                                                                 




In message <slrncmo8qa.a82.jgoerzen at christoph.complete.org> John Goerzen
<jgoerzen at complete.org> writes:
> 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 at 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 at combined.com
immediately