With gnucash is making good progress towards 1.6, it's time to start kicking around ideas for the long-term future. Is the existing codebase really the right tool to take us forward? Is our existing mix of C and scheme appropriate? Or are the limitations of our existing architecture too much, and should we be looking at something more radical? The "core" gnucash developers have been looking long and hard at this, and wish to present a proposal to the wider development community. In essence, we believe that C and guile suffer significant weaknesses - C's lack of memory management, the constant risk of dangling pointers, the lack of polymorphic typing, and scheme's consfusing syntax, lack of compile-time type checking, and poor performance under load, and with the current interest of many developers in testing and verifying the correctness of gnucash's code, these languages are simply underpowered. Hence, we would collectively propose that the gnucash codebase should be progressively converted to the language Mercury (http://www.cs.mu.oz.au/mercury), a project of the University of Melbourne. Mercury is a logic programming language especially developed for real-world projects. Initially designed to target compilation to C (and, as such, the fastest logic programming language available), it now supports compilation to a variety of high-level languages. It has an extremely powerful and accurate type and mode system, supports fully declarative I/O, has an excellent module system. Transition will be quite straightforward, as a bidirectional C-Mercury interface will be used to support legacy gnucash code. The nature of the logic programming languages make sophisticated verification techniques, such as program termination analysis, possible. CORBA and database bindings already exist, so the only thing we need to do is develop a language binding for GTK+. We're sure somebody from the wider community will volunteer. Additionally, as well as targetting C, Tyson Dowd has been working on a .NET backend for Mercury. This raises the fascinating possibility of easy porting to Microsoft's next-generation network environment. The core developers are all keen to work with quality Microsoft software, and this may make the transition possible. Non-core developers may be concerned about the total absence of resources to learn Mercury, and the opacity of the language. Don't worry, after a course in predicate logic, or a few months using Prolog, Mercury's extra features will only take a few weeks of consistent effort to learn. Besides, as long as we like it, that's the most important thing - and, if needs be, you can contact the originator of the Mercury Project, Dr. Zoltan Somogyi, whom all the Melbourne University alumni on this list can verify is incredibly helpful and loves dealing with newbie questions. Comments on this proposal are required urgently, but should be done taking into consideration the date at the top of this email. ------------------------------------------------------------ Robert Merkel [EMAIL PROTECTED] -- @James LewisMoss <[EMAIL PROTECTED]> | Blessed Be! @ http://jimdres.home.mindspring.com | Linux is kewl! @"Argue for your limitations and sure enough, they're yours." Bach _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
