Re: What's after guile-1.4? (was: Re: Questions... I am new to scheme)

[Greg Harvey <Greg.Harvey@thezone.net>]

Jeff Read <bitwize@geocities.com> writes:

> Russ McManus wrote:
> 
> > I would like to know more about what the guile team is planning for
> > future releases.  So far, I know that the focus for guile-1.4 is up to
> > date documentation.
> 
> I think the Guile team should pare it down a little. Make it a bit
> smaller and a LOT faster (especially when it comes to startup, and
> garbage collection). I was thinking, maybe you guys could borrow a few
> ideas from Perl's or Siod's GC. After all that's done, you can then
> attack the problems of bignum arithmetic and the numeric tower and that
> stuff. I believe that if Guile is going to achieve its intended purpose
> of being a ubiquitous, jack-of-all-trades embedded extensibility
> language, we have to make it an attractive option for people who're
> writing applications that could use such a language. A great way of
> doing this is by improving performance in a few areas and keeping the
> code size small.

The code size of guile is not any bigger than perl, python and
friends. If anything, with perl+libs or python+libs (and python
especially isn't all that useful without 'em), they're much bigger
than guile.

A comparison:
[greg /usr/local/lib]$ du libguile.so.4.0.0
412	libguile.so.4.0.0

[greg ~]$ du /usr/local/share/guile/
391	/usr/local/share/guile

[greg /usr/lib/perl5/i386-linux/5.00404/CORE]$ du libperl.a
719	libperl.a

(I estimate the perl libs at somewhere near the python libs, though
that may be very much under the actual size, it's hard to tell with
the inline documentation of pods, and I just don't care that much
about perl to get an accurate number).

[greg /usr/lib/python1.5/config]$ du libpython1.5.a
1606	libpython1.5.a

[greg ~]$ du -c /usr/lib/python1.5/*.pyc
	  /usr/lib/python1.5/plat-linux-i386/ 
	  /usr/lib/python1.5/lib-dynload/
2862	total

I'm assuming both the perl and python libraries have debugging
symbols, so they'd weigh in close to guile. Perl is mostly useful
without the spare librarys, so they're about the same; python is
pretty useless without the extra libraries, so it is, in fact, much
larger than guile, and having to keep track of reference counts in
extension c code is a pain in the ass. Even so, python is probably the
closest to what guile wants (or should want) to be: it has a lot of
available libraries to do damn near anything you want, and python
itself is a very managable language, both for quick hacks and larger
programs; perl may be fast, but it's not much more than obfuscated c
code taylored for string processing, which is great for very small
things, but can easily become a maintainance nightmare when it starts
getting large.

Tcl might be smaller, tcl+tk definately isn't (and how often is tcl
used without tk?). So guile really isn't any larger than the other
languages that are usually used for extensions. What needs to be
improved is the gc (perl & python's gcs are ref-counting, so that's
out; siod's gc isn't much different from guile's, and if I seem to
recall reading somewhere that guile's gc is mostly based on siod's;
the similarities are fairly obvious from looking at the code); the io
(outside of gc, this is what's really killing startup); and the module
system, which contributes both to the large startup time (there's a
lot of module code to read), and somewhat slower evaluation. Of these,
the gc and the io are being actively worked on (I think the io is, I
know the gc is), and a module system revamp is planned for after 1.4
(documentation is JimB's current focus, and it is the most important
element lacking in guile right now).

In any case, if you put guile on equal footing with perl and python by
compiling the init files, the startup time is very small. It isn't
done with the distribution, partly because hobbit doesn't seem to work
with 1.3, but mostly because JimB has some objections to it (I would
think the objection is to glossing over the problems, rather than
fixing them, and I agree (though it wouldn't matter if I didn't ;')),
though for end users it's definately something to consider (it does
make guile usable on low end hardware).

> Note that I really know nothing about hacking together a Scheme
> implementation, and many of you guys will probably know a lot better
> what to do about the GC problem, ice-9, etc. I'm kind of talking out my
> you-know-where here but I really think that being an extensibility
> library, addressing these issues is kind of a priority.
> 
> Oh, and why does it give me that IOT Trap error when I do read-line? Is
> that a libc or egcs thing?
> 

No idea. A gdb backtrace would probably be helpful for someone to find
the bug, though.

-- 
Greg