This is the mail archive of the guile@cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Elk/Guile (Re: Bad news from the module/environment front)


> As much as I understand Guile is based on SCM.  Is that correct?
> Are there special reasons for not having based it on Elk which seems
> to have precisely the same goals as Guile?

Change!! arrghgahgh...

There are a few differences -- you will have great difficulty getting
elk running without a C++ compiler. Now C++ is pretty widespread but
plenty of clunky old systems out there are still making do with clunky
old C compilers. scm is written in clunky old C style (with buckets of
#defines and nary a const) so scm is portable to a wider range of
machines.

Personally, I'm pretty happy to support just the newer systems,
anyone serious about numerical work will buy a new system without much
fuss. On the other hand, that reasoning doesn't apply to everyone.
Some people are doing embedded stuff using proprieary cross-compilers
(yelch!) and still want to use guile. Also, some people just don't
cope well with the concept of C++ compilers.

> Is there a debugger for Elk?  I didn't find anything like that.  Also
> the manual gives almost no hints.

Yeah, the debugger is not documented, I found it by reading the source.
Sheesh, how many times does that get said? You wait till you get
an error and then type

	(inspect)

Hmmm, I thought it was a dumb name too <shrug>.

> > Strange that you don't mention elk in your list, maybe it is
> > too new. However, it has a very focused target market -- application
> > developers who want an easy way to tack an interpreted extension
> > language onto their code. This is doubly dangerous to guile
> > because elk has hooks into various X toolkits so the lazy coder
> > can knock up widgetty front ends in elk while hanging some grunty
> > C on the back end. Every function is documented too.

OK, I take it back, every BUILT-IN function is documented,
the library of .scm files seems completely undocumented.
But scheme is such a self-documenting language (yeah right).

> >From what I have found on that WWW-page Elk is rather old
> (there is a nice reference
>   USENIX Computing Systems, vol. 7, no. 4, 1994
> which one can get as
>   http://www-rn.informatik.uni-bremen.de:80/software/elk/elk-3.0/doc/usenix/usenix.ps
> from which it seems that it has been available already in 1989).
> 
> But I'm in doubt if they are still active at the moment.

maybe I just noticed it because I found a binary distribution for
Debian and thought I'd give it a go. It seems like there are a lot of
scheme implementations out there, I also stumbled across umb-scheme
which comes with Red Hat 6 and doesn't seem to handle linking with
applications very well (though I only had a quick look). umb-scheme
is nice because it knows about rational numbers.

for what it's worth, I did finally get apt-get and guile1.3 going
from the binary distribution.

<philosophy warning>
It seems that scheme is at the point now where C was when every
com-sci student would be expected to write a C compiler as an exercise.
A lot of low level implementation has been done but high level issues
such as modularity are still up in the air. Mind you, the C coders
are just starting to get through the high level problems now with the
use of .so libraries -- even so a lot of libraries end up only used
by a single application. I see a lot of theoretical work on high-level
project-oriented design but not much on general principles of system
organisation, especially work that takes account of the amorphous mass
that is the free-software community (and for that matter any large
community).

	- Tel

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]