RFC: Rewriting gnucash in Mercury

[James LewisMoss]

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	                           rgmerk@mira.net

-- 
@James LewisMoss <dres@debian.org>      |  Blessed Be!
@    http://jimdres.home.mindspring.com |  Linux is kewl!
@"Argue for your limitations and sure enough, they're yours." Bach