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: Direction


Lalo Martins <lalo@webcom.com> writes:

> I feel that the current discussion about defined? and undefine
> is a sign of Guile's worst weakness; and that is, IMHO, lack of
> direction.
> 
> So let me throw some ideas around for comments, so we know what
> we're doing.
> 
>   What
> ========
> 
> The objective of Guile, as I see it, is to develop a powerful
> extension language (emphasis: extension, not scripting). Is good
> to know it's possible to create all-Guile software, but this is
> not the primary goal. Anyone disagrees?
> 
> 
>   How
> =======
> 
> Even if we agree on above, this doesn't say a lot. There are
> many concepts of "powerful" and many ways to get there.
> 
> These are the three major directions I see people trying to pull
> Guile to:
> 
> 1: generic extension library/interpreter. This is the direction
>    we advertise the most, and the one chapioned by projects like
>    CTAX, tcl->scheme, Sonya, etc. If this is the path we want to
>    follow, the priority should be in constructs to allow bizarre
>    Perl and Python constructs (one example that comes to mind:
>    Python's "type" type)
> 
> 2: a powerful Scheme implementation. Everytime I see "but Scheme
>    does this by..." or "the standard doesn't have this" or "this
>    is not schemely" I realize how powerful this "party" is.

Bow before the might of the schemers (or cl'ers incognito)! ;') I
don't think that you can really draw a line between the two, since
guile encompases the two.

1) The generic extension library, where you provide hooks, etc... into
   your program. Here we want to be able to modify and extend the
   application with any language which has a translator; we don't care
   much about scheme unless that's the language we're using.

2) The core, which is essentially a scheme implementation upon which
   everything is based; improvements here help everything, but are by
   their nature tied intimately to scheme (so why not be schemely? It
   certainly doesn't work against the first).


guile as a lousy scheme with lots of translators is pretty useless;
why take the performance hit of the guile approach when you could just
take the (possibly lesser) performance hit of using a funky corba
thing? guile without translators is just another scheme.

I don't think defining a direction changes anything (the idea of guile
eventually being able to handle anything you want to throw at it is an
official goal).  The scheme core still needs a lot of work. The
translators still need work, or need to be written (and any issues
they require of the core need to be dealt with as they arise). In
either case, what people choose to work on is going to continue to be
driven more by interest than an official guile direction. 

-- 
Greg