2.6 Release -- SCheme

[Donald Allen]

On Sat, Dec 31, 2011 at 6:17 PM, Derek Atkins <derek at ihtfp.com> wrote:
>
> On Sat, December 31, 2011 5:46 pm, Mike Alexander wrote:
>> --On December 31, 2011 6:22:55 PM +0000 Hendrik Boom
>> <hendrik at topoi.pooq.com> wrote:
>>
>>> On Fri, 30 Dec 2011 18:19:58 +0100, Geert Janssens wrote:
>>>
>>> This is probably a more drastic change than guile 2.0, but:
>>>
>>> There's another implementation of Scheme available that actually
>>> compiles  Scheme to C or C++ -- Gambit-C.  You can actually embed C++
>>> code within  the C code, even #include stuff.  There's also an
>>> interpreter, but the  interpreter doesn't have embedded C/C++ code,
>>> though it can call  previously compiled code that does.  The Debian
>>> package is called gambc. I have no idea whether this would be easier
>>> to use and maintain than  using guile.
>>
>> I don't know anything about Gambit-C, but it's also available in
>> MacPorts on MacOSX.  The description sounds promising.  The home page
>> is at <http://dynamo.iro.umontreal.ca/~gambit/wiki/index.php/Main_Page>
>> where they also link to Windows (and iPad!) installers.
>
> Is it really worth our time to find another scheme implementation and swap
> everything over to it?  I would think that it would be better to write a
> report infrastructure in a language that would seem more "popular"
> (python), build in the infrastructure, and then send out a call for report
> writers to convert the existing scheme reports over to the new language.

Much as I prefer working in Scheme to any other language for most
things, I was about to write the same message. Python is very usable,
well-supported and well-documented. And it's far better accepted in
the general community than Scheme. I agree completely with Derek.

If there is agreement among the developers that this is an attractive
alternative to Guile, I would advise doing some prototyping to
evaluate the performance of Python for report generation. My guess is
that it will be faster than Guile, but that's only a guess. It should
be tested before committing to it. One of the problems (and not the
only one) with the current report system is performance, and it would
not be smart to invest a lot of effort in a new system that had the
same problem.

/Don

>
>>          Mike
>
> -derek
> --
>       Derek Atkins                 617-623-3745
>       derek at ihtfp.com             www.ihtfp.com
>       Computer and Internet Security Consultant
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel