[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Texmacs-dev] Performance of Guile Scheme vs librep Lisp

From: Corey Sweeney
Subject: Re: [Texmacs-dev] Performance of Guile Scheme vs librep Lisp
Date: Sat, 12 Nov 2005 18:33:23 -0600

A couple of comments:

>From what I've heard, guile has many features that make it impossible to fully compile.  However some of these features are really cool.  (I wrote a "persistance" system for guile-scheme in about 10 lines of code (note: it was unoptimized.  I didn't need something to work well, I just needed something to work "good enough".)).

I also get the feeling that guile scheme was never optimized.  If i remember correctly, optimization was going to happen "in the future" which never came.

Also, I believe (but havn't checked) that rep is not syntactically compatible with scheme, meaning the texmacs scheme code would have to be rewritten/reworked.

Yes the guile-gnome module exists, but the corba links have been broken for years.  The "gnome vision" that I bought at "gnome <1.0" was that all applications were to be bonobo (corba) objects, and have user guile scripting language, so a user could via guile assemble program components into a new program.  I'll say that again, so a *user* could via guile assemble program components into a new program. This was basically giving programming abilities to those with just "scripting" skills.   However this never actually happened.

I essentially see texmacs as a competing platform to the gnome environment.  (This is me saying this, not joris :)

Of course it would be nice if texmacs handled the gnome "session managment" requests.

A couple things you may be interested in:
* Stalin - a scheme that compiles very fast, but dosn't support the whole scheme language.
* plt-scheme (also called "dr scheme")  - a scheme with a large user/development comunity.  Currently there is no "offical" gtk/gnome support in drscheme, but it's in the works.  (I have a pre-copy right now).  Plt also has the ability to compile parts of your program into native assembly & some other really cool things like reader macros! (in version 299.405)
* bigloo - another scheme with a comunity.

also: freedesktop.org . That's pretty much everything that KDE and gnome have agreed on a interoperable standard for.

And while joris has a big "todo list", if you had the time to port to a faster language he'd probably accept patches ;)

If you would like to talk about these any further, feel free to email me.  It'd be best to email me directly and leave the list for discussions of stuff that might actually get implemented in the near future. :)


On 11/12/05, Karl Hegbloom <address@hidden> wrote:
On Sat, 2005-11-12 at 15:12 +0100, Joris van der Hoeven wrote:
> Yes, if the choice of Guile were to reconsider, there would probably
> be several good alternatives. The problem is that this is quite
> difficult in the near future, because our task-list is already
> full with more urgent things...

I wrote that stuff about 'librep' vs Guile from previous knowledge,
without even looking at the relative status of the two projects.  It
appears that 'librep' is no longer under active development.  That is a
shame, perhaps, since it is such a nice little Lisp_1.  I think that
every computer science student and hobby-hacker should read it's source
code.  There is a lot to learn from it.  It's virtual machine is tight
and quick.  John Harper, the author of 'librep' told me that his thesis
had to do with CPU cache performance issues, and the design of the
'librep' VM is such that it is meant to reduce cache misses, helping to
make it run faster.  The indirect-threading method with the jump table
(vs switch statement) is really slick.

Of course there is also a lot to learn from the Guile implementation.
It has features lacking in 'librep' (objects and generic methods), and
is still being actively developed.  It is in use by many Open Source
software projects as well.  GnuCash is really coming along nicely, for
instance.  They have the 'g-wrap' thing working to great effect,
wrapping their C code very automatically.  There is also a
'guile-gnome-platform' project, which also uses g-wrap.  From the
"HACKING" file:

        GNU arch is a source management tool that is particularly
        well-suited to modular, decentralized hacking. It is what we use
        to manage our code. The canonical source for guile-gnome is our
        arch archive, address@hidden:

           $ tla register-archive address@hidden \

        guile-gnome is developed as a set of modular source packages. To
        check out guile-gnome, the first thing you will need to do is to
        check out the `dists' package:

           $ tla get address@hidden/dists--dev--0 \

        This will check out the `dists' category into the
        directory. The next step is to configure the source tree for a
        given set of wrapsets. Build configurations are kept in
        configs/gnu.org. There is a `dev' configuration for
        bleeding-edge hacking, and versioned categories for releases
        that have already been made. For example, to check out the 2.6.0
        platform release, you could do the following:

           $ tla build-config -r

And, for those who aren't already aware of it's location, the Guile
Scheme development sources are apparently at:


I personally have not had as much time recently for the study of Guile
and Guile-Gnome as I'd like to have, but expect that after this years
Mathematics and Logic, Discrete Mathematics and Computability Theory
courses, I'll be better prepared for understanding it.  (Perhaps next
summer, if that's what I wind up doing then.  At that point I can learn
whether a byte-code VM is viable for Guile.)  I really want to learn
more about the internal workings of that kind of software subsystem.
Languages can be quite intriguing.  I also plan at some point to learn
more about how the classical TeX system works, and more about CAS

Karl Hegbloom <address@hidden>

Texmacs-dev mailing list

((lambda (y) (y y)) (lambda (y) (y y)))
reply via email to

[Prev in Thread] Current Thread [Next in Thread]