[Haskell-cafe] Monad applied in Java
My apology to those who don't care about Java. Please trash this note. I recently published two open source Java projects that are based on the Monad computation model learned from Haskell community. 1. A port for Parsec. This library is called Jparsec. It implements monadic parser combinator in Java. Not nearly as concise and clean because of the limitation of the Java language, but it implements the same idea. And it looks like the only monadic parser combinator lib in Java so far, according to my google homework. ;--) url: http://docs.codehaus.org/display/JPARSEC/home 2. A light-weight Dependency Injection container that's built around the Monad model. If you see sequence id=mybean bean var=a1 class=A1/ bean var=a2 class=A2/ method class=X name=create args=$a1,$a2/ /sequence You'll know what I'm talking about --- do-notation. With a bunch of bind calls under the hood, it is equivalent as saying: do a1 = bean A1 a2 = bean A2 method X create [a1,a2] url: http://docs.codehaus.org/display/YAN/home This is the only ioc container that uses Monad model in Java. Just FYI. Any comment is welcome. Ben.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell's overlooked object system: was OO idioms redux
Looks like my worry is pointless. :- I was just afraid that Haskell may pick up another object monster. (And I'm a C++/Java programmer) Although I still miss a simple primitive language construct to do 'extensible record', it is definitely a nice work both theoretically and practically to present an OO library. And I'm totally with you guys about 'leaving choices to others'. My belief is: the more orthogonal, the better. Cheers, Ben. Ralf Laemmel [EMAIL PROTECTED]To: [EMAIL PROTECTED] Sent by: cc: haskell-cafe-bounces@Subject: Re: [Haskell-cafe] Haskell's overlooked object system: was OO idiomsredux haskell.org 10/14/2004 09:21 AM Graham Klyne wrote: At 22:17 13/10/04 +0200, Ralf Laemmel wrote: ... We reconstruct OCaml's tutorial in Haskell ,,, I think that's interesting as a theoretical exercise, but I don't currently see myself using that framework in practice, in the form presented. As you say Simply syntactic sugar would make OOP more convenient in Haskell. Just for clarity ... As Oleg said, we would like to refrain from judgements regarding - OO in general - the urgency of combining all of OO with FP - the urgency of the combination in the case of Haskell. We have (varying) opinions about that ... but the OOHaskell effort is about showing that Haskell readily comes with an object system, or the ability to express it. That's it! At a more arbitrary level, we opted for an OCamlish object system because OCaml's system is definitely a good benchmark in terms of the many idioms covered. It is also a rewarding approach because OCaml's relies on non-trivial language extension, where our OOHaskell approach uses Haskell's existing type system to bring OO to Haskell. This is very, very rewarding for Haskell aficionados, indeed. We are also looking at OHaskell, Haskell++ and others, whose publicaly available examples should eventually become available for OOHaskell as well. When we think of syntactic sugar then this is merely about keywords such as class, interface, begin, end, method, ..., which some people might ask for anyway. With an OO hat one, people might want to really see the different forms of absractions methods, mutable fields, classes, mixins, while from an FP point of view functions and records are totally sufficient. Anyway, some of these keywords can be provided quite conveniently just as combinators. These combinators would then perform additional type-level checks or they are just NO-OPs. Personally, I wouldn't want any syntax extension. To summarise, what's very important in our view is that OOHaskell shows that no language extension is needed to bring OO to Haskell. And even in the case where we end up providing syntactic sugar then this is about surface syntax whose reduction to normal Haskell syntax is a *local structural mapping* as it could be peformed by the most trivial preprocessor or macro system. So the type system of Haskell is fit for OO. That's cool. From a practical perspective, the foundation of OOHaskell to depend on HList implies that type errors are potentially inconvenient depending in turn on encoding details of the type-level code. For example, it takes some coding effort to teach the type-level implementation such that you see type errors that are anywhere close class a found but class b required or class a is not a subclass of class b. The HList paper discusses some idiom for better type error messages in type-level code. A mail by Oleg on keyword arguments discusses another idiom, a CPS-like trick, but there is more work to be done. It is encouraging to see that the OO structures can be constructed within the Haskell type system. Absolutely. Would it simplify your approach significantly to focus on non-mutable objects? (In recent discussions with
Re: [Haskell-cafe] OO idioms redux
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
[EMAIL PROTECTED]To: John Goerzen [EMAIL
PROTECTED]
ford.ac.ukcc: [EMAIL PROTECTED]
Sent by: Subject: Re: [Haskell-cafe]
OO idioms redux
[EMAIL PROTECTED]
l.org
10/13/2004 08:15 AM
In message [EMAIL PROTECTED] John Goerzen
[EMAIL PROTECTED] 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
[EMAIL PROTECTED]
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 [EMAIL PROTECTED]
immediately
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell's overlooked object system: was OO idioms redux
Some people say that ocaml's object system is kinda useless. The best support I hear so far was:it does not hurt implementation inheritance, the strange # syntax, virtual method, why do I need them? In Java, people are doing programming-against-interface, implementation injection etc. All these show that we don't need implementation inheritance to be OO, and implementation inheritance is in many cases bad practice anyway. As somebody pointed out, we could do interface in Haskell with record. The only problem is names. If we could, as we can in OO languages, provide a separate namespace for the fields of each record. We are pretty much done. The rest is some kind of record coersion+row polymorphism mechanism. If haskell can do what Simon P. Jones and Mark Jones described in the paper Lightweight Extensible Records for Haskell, I'd say it is a already a nice functional OO language. Compared to Ocaml, 'OO' support is seamlessly integrated with the functional part. It leaves no redundancy, no overlapping in the language. In short, what if we don't create an object piece that competes with the functional part, but fix and enhance the record system that we currently have? Ben. 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 [EMAIL PROTECTED] immediately ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell's overlooked object system: was OO idioms redux
Why do you (or do these people) think having all the OO idioms of OCaml (see OCamls OO tutorial) is useless? Or do you mean too baroque? If not, what's missing? Because it does not give us much that we cannot do nicely with the current functional part. separate name space of course. But it does not seem obvious that the rest of the object piece is necessary. Anything missing? Can't think of one. Simplicity I guess. implementation inheritance, the strange # syntax, virtual method, why do I need them? Fine with me. OOHaskell doesn't need them, indeed. Nice. Well having no implementation inheritance in Java would be a pretty brave limitation. Anyhow, OOHaskell (and OCaml) has programming-against-interface as well. It may be. But is it a brave limitation that Haskell does not have implementation inheritance? I don't see the absolute need for impl-inheritance in an already rich and integral language such as Haskell. If impl-inheritance is already an arguable feature in OO langauges, I guess more thought should be given before it is pushed into a functional language at the cost of language complexity. (All I'm saying is general concern, it does not refer to HList or OOHaskell because I have no knowledge about them) Have you seen HList? There are 4 different solutions for first-class labels in the distribution. No. I'm just throwing in some ideas. If it is irrelavant or something already done, my apology. :) But, hey, don't get me wrong. I have no problem to see the language supporting impl-inheritance and other OO features. What I'm against is to invent a whole new standalone object system like what Ocaml has. In other words, it should not double the size of the language. The rest is some kind of record coersion+row polymorphism mechanism. Yes, good point. That's what we meant: the object system in Haskell has been overlooked. Haskell 98 does not have row-polymorphism, does it? Or am I overlooking something? If haskell can do what Simon P. Jones and Mark Jones described in the paper Lightweight Extensible Records for Haskell, I'd say it is a already a nice functional OO language. It can readily do more than that: http://www.cwi.nl/~ralf/HList Thanks. I'll certainly find some time to digest it. Compared to Ocaml, 'OO' support is seamlessly integrated with the functional part. It leaves no redundancy, no overlapping in the language. What are you referring to? I mean: where is OO support seamlessly integrated with the functional part? Do you refer to OOHaskell? No. I did not look at OOHaskell yet. What I mean by seamless is the 'extensible record' proposal. It is not created for OO, but it can be used to do OO. Whatever I do, it is just an orthogonal piece of facility. While Ocaml objects and functional part don't look quite orthogonal. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] 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 [EMAIL PROTECTED] immediately ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rethinking OO idioms
You can use state monad to mimic mutation. Also, take a look at the recursive decent monadic parsec library. It may have done what you are trying to do. Regards, Ben. John Goerzen [EMAIL PROTECTED]To: [EMAIL PROTECTED] g cc: Sent by: Subject: [Haskell-cafe] Rethinking OO idioms haskell-cafe-bounces@ haskell.org 09/29/2004 03:29 PM I've worked with languages with object-oriented features for awhile now. Python and OCaml, the two with which I work the most, both have OO. One of my first projects in Haskell would be to write a Haskell version of Python's ConfigParser[1] class. I wrote[2],[3] a version of this for OCaml that works very well. In a nutshell, ConfigParser is a utility for working with sectioned configuration files in a style similar to the familiar .ini files from Windows. It has methods to read a configuration file, get/set the items that are being configured, and write a new file back out. This, then, is a fairly typical metaphor for OO programs: an instance of a class has some state that can be accessed or modified, and possibly stored and retrieved. So I am thinking about a ConfigParser for Haskell. The first thing that occured to me is that Haskell has no OO features, so I'm not sure what is the best way to handle the class and its various methods. The next thing that occured to me is that, unlike OCaml and Python classes, Haskell has no mutable variables. A call like config.setOption(main, initpath, /usr) in Python -- which alters the state of the config object and returns nothing -- would be impossible in Haskell (unless perhaps the FiniteMaps are mutable somehow?) I guess I'm having trouble translating this common OO language paradigm into the Haskell world. Thanks for any insight. -- John BTW, if I get a working ConfigParser for Haskell, I will publish it under the GPL like all the rest of my code. [1] http://www.python.org/doc/current/lib/RawConfigParser-objects.html [2] http://gopher.quux.org:70/devel/missinglib/html/ConfigParser.html [3] http://gopher.quux.org:70/devel/missinglib/html/ConfigParser.rawConfigParser.html ___ Haskell-Cafe mailing list [EMAIL PROTECTED] 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 [EMAIL PROTECTED] immediately ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
