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: Planned presentation at The Bazaar



sds@goems.com writes:
> 
>  >> ((lambda (x) (list x (list (quote quote) x)))
>  >>  (quote (lambda (x) (list x (list (quote quote) x)))))
> 
> cool! can I quote this on my page? (with proper reference, of course; is
> this original by you?)
> 

I thought it up myself right before posting, but I later found this
expression has been reinvented many times. The more I think about this
expression, the more I like it: it beautifully demonstrates many of
the greatest advantages of the Lisp language family (most notably
first-class functions and the tight code/data relationship) in a very
small space.


Regarding the below:

Oh boy. I am really hesitant to get into "my favorite language"
discussions. In fact, Common Lisp vs. Scheme is such a classic in this
area that it's best avoided. I will outline some reasons why I think
Common Scheme will (a) come to pass and become a standard and (b) will
be better than Common Lisp. For the sake of fairness I will quote your
remarks in full.

>  >> I agree with you, but I think Guile is actually moving in this
>  >> direction, i.e. an embeddable language with the scope of Common Lisp
>  >> but based on a Scheme core. In particular, it already has hash
>  >> tables, structures and arrays (all these features could be
>  >> implemented better, but this is actually being done). 
> 
> These are not standard scheme (R5RS) features.  Other R5RS extensions
> could implement these differently, and voila - we will be with all the
> different `schemes' where we were with various lisps in the early
> 80-ies, when CL was started.  Why not use the results of 15 years of
> progress now, instead of reinventing the wheel like MS does?
> 
> We are getting another ELisp here - a language strongly identified with
> its implementation.  Soon, SCWM et al will not be extensible "with
> scheme" but only with "Guile", the crucial difference being that you
> cannot replace implementation - you are stuck.
> 
> IMO, standardization here is crucial - it makes the application
> developer independent from from the extension-language developer, so
> that if someone comes up with a better implementation, you can easily
> switch. 
> 
>  >> (btw, libguile is 380k stripped, not 1M and I'd like to see a
>  >> libclisp that comes within an order of magnitude of that).
> 
> Well, CLISP is a 1.5 mb executable.  Size is not a big deal.  An extra
> MB matter little these days.

Yeah, but per-binary runtime size does count somewhat (unless you have
a server-based implementation).

> 
>  >> I know tastes vary, but I personally would much rather use a
>  >> hypothetical Common Scheme than Common Lisp.
>     ^^^^^^^^^^^^!
> 
> Exactly!
> Now, the only advantages of Scheme over CL are simplicity and smallness.
> When they are gone from Common Scheme, what will the advantages be?
> Why not stick with the existing CL, with several robust implementations,
> rather than reinvent the wheel?


a) Why Common Scheme will, in effect, happen, and will not be tied to
a specific implementation:

It is true that many Guile features are not R5RS standard. And it is
true that the way the Scheme standardization process worked, only a
small core typically ended up in the standard. However, in my
(somewhat educated) opinion, the Scheme community has been fracturing
into at least two camps for some time: the camp that wants a really
tiny language of mostly academic interest, and the camp that wants to
be able to protably use a wide range of functionality for professional
worl. Guy L. Steele himself admited to and somewhat encouraged this
process on the rrrs-authors list.

Recently, at an ad-hoc meeting for discussing straw-man proposals for
possible Scheme standardization, a number of core features were
recommended for standardization to the RnRS authors, and more
significantly, there was a general agreement to form a repository of
documents standardizing various extensions to Scheme; these would not
be part of the RnRS standard but so-called RFIs (Requests For
Implementation). These will have the net effect of standardizing
popular extensions because implementors will be highly motivated to
satisfy the RFIs when adding extensions.

It may even happen that certain RFIs might get explicit mention in
future Scheme standards.


b) Why Common Scheme would be better than Common Lisp, in my opinion:

* Cleaner semantics. To name a few examples:

** I really dislike the separate function and variable namespaces in
CL, the fact that the operator is evaluated by different rules than
operands, and the gyrations you have to go through to get around them.

** Scheme has hygienic macros (I admit I haven't yet used them in a
significant project, but I am glad they exist).

** I like the Scheme naming conventions better than the CL ones.

** Guaranteed proper tail recursion is good.

** I don't like CL's concept of a symbol having explicit value,
function, property list, package etc slots.

** I don't like the way CL handles booleans (neither the fact that
they are special symbols or that (eq nil ()).

** I don't like the tangled CL type hierarchy.

** In general, almost anywhere that Scheme and CL both address the
same issue, I like the Scheme answer better. (One notable exceptions:
I like CL's syntax for complex numbers better). CL's advantage right
now is that it addresses many issues in the standard that need to be
addressed individually by each Scheme implementation.

* I expect features added to Scheme, either the core or standardized
libraries, will also be very carefully considered and will have clean
semantics as above, as well as being more streamlined.

* A small *core* lanaguage. To me, the important thing about Scheme's
simplicity and smallness is not so much that the whole language is
small (any useful implementation extends it), but that there is a
small, well-defined core. If a good set of libraries were standardized
in addition to this core (whis is in effect happening) and if a few
key features got added to the core (most importantly a module/package
system), this property would be preserved, while providing the
functionality that the Scheme/Lisp programmers of history have found
useful in a neatly partitioned way. Common Lisp, by contrast, is a
big, monolithic beast. It is hard to take out a small subset on the
basis of which the rest of the language can be understood. I had a
hard time reading CLtL the first time because there was just so much,
and it was hard to find the important bits. Even the ISO committee
standardizing ISLisp is going with the core+libraries/layers
approach. With a small core and disciplined extensions, it will still
be possible to write a formal semantics for the core fairly easy, and
define everything else in terms of that. 

* Some IMO gratuitously useless and annoying CL features, like the
`loop' macro, will hopefully be left out entirely.

* More generally, just because we have a good, featureful language in
the form of CL, is that a reason not to try to do better in achieving
similar goals? You could call this a mere "reinventing [of] the wheel"
but I think it is possible to end up with cleaner, nicer semantics by
starting from scratch and rethinking everything (on top of an already
clean core) than to just accept the effects of evolution and live with
them. I think that in some sense GNU/Linux has done this for
traditional proprietary Unix - through rethinking of key issues in the
GNU tools and the Linux kernel, a much more pleasant and consistent
system has resulted.


Overall, though, I'd rather use _any_ language in the Lisp family than
C/C++/Java for any task not best done with the (semi-)portable
assembly languages these in effect are. I think the community centered
around various Lisp-family languages really has much more to bring
them together than to keep them apart, and that is often forgotten in
language wars. I think the page on the Lisp family of languages linked
off your homepage has a very good point - Lisp _is_ a family, and
there are good reasons to have more than one, just as C, Objective C,
C++ and Java all have reasons to exist.

 - Maciej Stachowiak