Ticket #1575 (closed proposed-project: wontfix)
Rewrite xmonad in Java
|Reported by:||Feuerbach||Owned by:||Feuerbach|
|Difficulty:||3 people Summer||Mentor:||not-accepted|
There are many problems with first-class functions -- they cannot be compared for equality, serialized etc. This makes a lot of inconveniences for xmonad developers, some of these problems were discussed on the mailing list recently. I think the most obvious solution is to rewrite xmonad in a language which does not support first-order functions. Although it's not trivial to find such language, I think I did -- something called Java.
Now, you ask, why do I propose this project for Haskell.org? Well, there's no such mentoring organization as Java.com (or even com.java). Besides, there's apparent profit for the Haskell community. It is well-known that xmonad serves as the source of many new Haskellers. First they search for a usable window manager, then they find one and must learn a whole language to configure it, then they like the language and start use it. Surely this doesn't help avoiding success at all cost.
xmonad users will also benefit from such rewrite. I haven't decided yet whether new xmonad config will be in Java itself or in XML. In the first case, we have an ability to use a lot of design patterns there, which makes it easier for users to get familiar with configuration (because, you know, today everyone knows design patterns). In the second case we don't need a Java compiler to be installed, and since XML is standard there are many editors there which make XML editing easy and straightforward. But in either case it will be more readable than current conglomeration of combinators.
Finally, I don't think we need that frightening name "xmonad" any more. How about "xfactoryfactory"?