This is the mail archive of the email@example.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]|
Lalo Martins <firstname.lastname@example.org> 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