Re: Planned presentation at The Bazaar

[Greg Harvey <Greg.Harvey@thezone.net>]

Maciej Stachowiak <mstachow@mit.edu> writes:

> 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. 

It's fun, though ;) Besides, I think the focus here is more on how
guile should approach adding extra features, rather than why cl/scheme
is so much better/so much worse than the other, so it likely won't get
to a frothing at the mouth, nya nya nya your language sucks sort of
deal. 

> 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?

The problem with cl is that the standardization wasn't based so much
on refining the features of the language, as making sure that most of
what already existed in lisp implementations would still exist in
future implementations. A lot of vendors had vested interest here, and
the direction was more one of avoiding breaking existing code, rather
than making cl as consistant (syntactically, at least) as possible.

Scheme isn't really in the same boat, for a couple of
reasons:

1) Any code that's been written for more than one implementation has
   basically stuck to the core constructs of the language. Anything
   that targetted stuff not in the core were mostly being written for
   one implementation

2) Less money involved, and therefore a less determined push for one
   feature or another (ignoring egos ;). I can think of a couple of
   lisp/cl vendors, but no scheme vendors come to mind. Scheme's been
   more of an academic language until now, which could actually give
   it great advantages when it comes to moving into the 'real world'

I seem to recall that Ken Pittman's web site gives some insight into
some of the issues involved with the standardization process for cl,
and some nice bits on lisp in general. I think most of the interesting
stuff starts at http://world.std.com/~pitman/publications.html, though
it might require a bit of poking around.

> > 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).

It depends on what it's being used for. If you want to do scripting,
then you want a small, sleek guile, ready to fire up at a moments
notice. On the other hand, if you're extending a giant image
processing application or web browser (or writing one in `Common
Scheme'), an extra meg here or there isn't going to cause many
sleepless nights. The library approach will allow a lot of
flexibility, rather than requiring a humongous core.


> > 
> >  >> I know tastes vary, but I personally would much rather use a
> >  >> hypothetical Common Scheme than Common Lisp.
> >     ^^^^^^^^^^^^!

It should also be noted that the existance of a group of standardized
features in scheme would make it quite trivial to implement a cl
compatable module, so that everyone's tastes can be catered to. I have
a few modules laying around that provide some cl style things, like
generic operations on sequence types, some type operations & typecase,
and other things that I find useful in cl, but that don't necessarily
need to be a part of a standard library or core language, since
they're trivially implemented on top of the core language and follow
the already defined semantics of cl. Some of the other bits I have,
like optional & keyword arguments, really need to be part of a
standard, because everyone implements them differently, and it's
probably a safe bet to assume that native argument handling will be
much faster than scheme based argument handling. It would also avoid a
'what the hell is that!' situation when looking at code from another
scheme implementation.

> > 
> > 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.

I've seen this mentioned here a few times (is there a site,
btw?). What I'm wondering about is what's to prevent there from being
50 different documents proposing a standard for the same thing? Or
will there be a similar process to the acceptance of features in the
core language for extension proposals? If not, the situation won't be
terribly improved, you'll just have every implementation submitting
RFI's for their own pet features, and endless squabbling over whose
code is the best.

> 
> 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.

It does allow you to use list as an argument, though :) (small win,
but it's part of the reason that cl's macros don't encounter too many
problems)
 
> ** 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.

The biggest flaws of CL generally stem from incorporating most
features of a bunch of lisp implementations, and then sorting them out
as best as could be done. This is glaringly obvious when it comes to
mutating vs. copying functions (some start with n, some are completely
non-obvious, like delete vs remove). It's understandable, in that cl
was based more on picking through what existed than inventing better
solutions, but it's still a hassle.
 
> ** 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.

Also has the advantage that, if one implementation can be agreed upon,
and the code is made freely available (is that a requirement for
sample implementations of rfi's, I wonder), then more effort can go
into improving and optimizing one bit of code, which will benefit all
scheme implementations, while not preventing anyone from reinventing a
well defined wheel if they so choose (sometimes it's a bit of fun).

> * 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.

(loop is a language war in itself downto argh!) I personally think
loop is tremendously useful, but it could be more lispy. Since scheme
doesn't need compatability with older loops, it could chuck the bare
word syntax of CL loop, and go with a more sensible approach, i.e:

(loop (for i from 1 to 10)
      (collecting (* 2 i)))

In comparison to some of the funky iteration constructs of cl &
scheme, I think loop is a lot more readable. This definately fits into
the catagory of standardized but optional, though, because it's still
not *that* lispy, and for each person who loves it, you can find a
person who absolutely despises it.

> 
> * 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.

I think that we should avoid situations where we make things
gratuitously incompatable, just for the sake of creating a new thing
(which is sometimes the feeling I get when using scheme... for
example, all the different ways of representing keywords, when it
would've been just as easy to use :foo, and would've prevented much
profanity on my part). There are some really nice bits of cl; clos,
the existance of fairly generic functions on types that are closely
related (i.e. elt on sequence types), host independent pathnames
(after you've stared at it for a few hours and it starts to make some
sense ;).
> 
> 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.

Debatable >;)
 

-- 
Greg