RFC: rewriting gnucash in Mercury (fwd)

[linas@linas.org]

What's today? April 2nd, I think? 
This idea is a day late and a dollar short, in my opinion.

--linas

Forwarded message:
> From: Robert Graham Merkel <rgmerk@mira.net>
> To: dave@krondo.com
> Subject: RFC: rewriting gnucash in Mercury
> Date: Sun, 01 Apr 2001 16:16:36 +1000
> 
> Dave, you might like to forward this one on to gnucash-devel, if you
> think it's appropriate . . . 
> 
> 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
> 
> <telsa> I left my client on #gtk+ overnight and there was nothing 
> in scrollback at all except quit/rejoins.
> <bighead> telsa: well its been that for, I think 3 days now 
> (ever since started coming back on IRC)
> <telsa> Clearly they are busy implementing telepathy, 
> and dog-fooding it. :) 
> ------------------------------------------------------------
> _______________________________________________
> gnumatic-internal mailing list
> gnumatic-internal@lists.gnumatic.com
> http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnumatic-internal
>