This is the mail archive of the guile@sourceware.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]

Guile focus


> > FWIW, I'm in the standalone interpreter camp. 
> 
> Yeah, but then we'd have to change the name to GUIL. The big, official
> purpose is embeddible general purpose language interpreter; making the
> scheme side better obviously improves the final result, so the goals
> aren't necessarily exclusive.

There are a lot of scheme standalone scheme interpreters,
but rather less embeddable ones so it seems to me that filling the
hole is more productive than reworking minor variations on an
already overused theme.

Also, the embedded side of the equation is the more difficult constraint
because just about every embedded system will somewhere have a some
console that gives you REPL access -- it pretty much has to for debug
and development purposes -- so the standalone scheme system has to
exist anyway. However, successful embedding requires MORE than that,
it also requires a cohesive garbage collection strategy that cooperates
with foreign C code and it requires an API that is small and sensible
enough to learn quickly and which operates cleanly so that the foreign
C code doesn't have to be twisted into shape to suite a quirky scripting
API. These additional constraints make things like MIT scheme difficult
to embed (just to take an example).

If it hasn't been said enough already, anything intended for embedding
should be small.

> > In any case, if I needed to embed an interpreter, I wouldn't choose
> > guile.  I would choose either mzscheme or python.  There are two
> > reasons for this:
> > 
> > 	1)  lack of preemptive threading (relatively major downside)
> > 	2)  lack of documentation        (HUGE downside)

I have only briefly looked at the way python's embedding API but
the mxscheme did look quite nice, although I must say I found it still
suffered from monolithism and high complexity -- it's not the sort of
thing that you could grab onto and get up and running quickly.

> Docs yes (I'm pretty sure we've beaten this one to death). I'd expect,
> tho, that most people aren't too concerned about preemptive threading
> (probably because most of us are running on single cpu systems, so
> we'd end up with worse performance on account of it ;).

I've never used threads and don't have any immediate intention to start.

> Actually, it didn't necessarily need that (and should've applied to
> previous versions, with fuzz); but it is more a problem of the
> cvs/diff method often not being too brainy about conflicts (this is
> the reason why those `open' licenses where you can only distribute
> changes by patches suck).

If you are talking about gnuplot then I agree with you.
I suggest that any patches you do release should be released as GPL
which would be incompatible with the original licence so that they
become ``unmergable'' into the original. If the patches you release
are useful enough then a lot of people will see how silly the original
licence was. Maybe that is against the spirit of cooperation, I dunno.

> There's nothing I hate worse than getting a
> patch where you have all these odd things happen when you do a patch <
> stuff.diff; I stressed the particular cvs version to make sure that
> people interested wouldn't have to deal with all that crap. The
> patches for the next while will be against 1.3.4, so that's easier ;).

Regular ``unstable'' releases help by reducing the number of possible
points that patches can be based on. There are a few other things that
can be done to help the process, firstly make the code as modular as
possible so that changes are USUALLY happening in concentrated blobs
rather than as a fine spray (easy to say, difficult to do, probably
requires careful study of where the previous changes fell and which areas
tend to relate to each other). Secondly, maybe use an auto-formatter
like ``indent'' to ensure that the diffs are consistent. I know that I
don't much like indent's results but I have a hacked version that
suits my style of coding, other people probably have the same. If the
CVS tree was set to some particular style and all diffs and patches made
using that style then everyone has a set base to begin from.
Thirdly, CVS is also open source so if anyone can find a way to document
the problems that it has then at least there is something that can form
a base for improvement.

> > To finally put my response on topic, I personally think goops *should*
> > go into the core if people want guile to have a CLOS-like object
> > system.

Anything that makes the core smaller is good,
anything that makes it bigger is bad.
Easy to test for, easy to understand.

> I'm not saying goops shouldn't go into the core (I also think goops
> *should* be in the core), but I'm saying that it should have
> documentation before it's added: if not, then it still won't be used
> very much. However, it looks like someone's started to work on this,
> so hopefully this point will be moot before too long :)

Same with the API, the smallest API is the best, people simply will not
learn a lot of complicated calls and unless they can get up and running
in an hour or two they will probably give up. I haven't studied GOOPS
yet but I briefly looked at CLOS and the first thing that hit me was
so many unfamiliar symbols and calls, so I shelved the whole idea and
haven't looked at it since.

Having buckets of documentation is nice, but having elegant, simple ways
of doing things is nicer.

	- Tel

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