Cc: srfi-13@srfi.schemers.org
Newsgroups: comp.lang.scheme
Subject:  Boyer-Moore code & Common Lisp
>From: Olin Shivers <xxxxxx@lambda.ai.mit.edu>
Date: 24 Nov 1999 12:16:59 -0500
Message-ID: <qijwvr7xxxxxx@lambda.ai.mit.edu>
Organization: Artificial Intelligence Lab, MIT
Lines: 65
X-Newsreader: Gnus v5.3/Emacs 19.34
--text follows this line--
   Date: Tue, 23 Nov 1999 00:22:40 -0800 (PST)
   From: Brian Denheyer <xxxxxx@seanet.com>

   This is probably one of many submissions.  Let me know if it's useful,
   or needs work, or if the temperature in the theater is not to your
   liking.  I will do my best.

Brian, you rule. Thanks for the code.

   It's GPL'ed.  GPL'ing things is now very fashionable.  The GPL is also
   good with lots of soy sauce.

Yum! You know, I never used to GPL my code. But I was at a party when I was in
high school, and a bunch of my friends were doing it, so, you know, I tried it
out.  I didn't really like it, actually. But now, I like it a *lot*, and I do
it a lot.

But I could quit anytime I wanted.

   BTW, is it just me or are all these SRFIs starting make scheme look
   like CL ?  I've been wrestling with the CL vs. scheme question lately.
   Any thoughts on the matter ?

Hell, yes. Here is the good thing about CL I'd like to get "into" Scheme:
It has a rich, powerful and *completely* standard, portable toolkit
of procedures & linguistic features (exceptions, records, modules, objects)
on which programmers can completely rely.

Schemers may sneer at C and perl. But these languages are much, much better
tools for writing *portable*, interesting programs that do real things. That
fact just really bugs me. I'm not content for Scheme to be a language that
one uses to instruct college students, who then are shipped out into the
world to do real things... in C and perl.

There are also things about CL I *don't* like, by the way:
  - The module system is pretty bad.

  - CL perpetuates bad, old ideas, especially
    + distinct function/value binding spaces,
    + the confusion between symbols (data structures), and variables
      (language-level elements),
    + the bizarre nil list/symbol duality

  - CL's design was influenced by a lot of backwards-compatibilty
    issues. At the time, the LispM/Zetalisp camp were in a position
    to make a lot of demands on compatibility -- had they walked, it
    was generally felt the CL "coalition" would fall apart or be
    irrelevant (hard to believe in retrospect, but true).

There's another mixed-bag feature in CL, which is the complex
parameter-passing machinery. This is powerful and useful. In
particular, it allows you to define *one* procedure with many
optional knobs & dials, any one of which can be specified in
the non-common cases. Scheme requires you to define different
procedures for the various sets of parameters you expose, with
potentially combinatorial explosion in the set of name bindings
generated.

On the other hand, CL's parameter-passing machinery is really
hard to analyse, optimise or check statically. I don't like that.

I cling to another distinction between Scheme & CL. Common Lisp is a *big*
language. I don't mean the subroutines & data types. I mean the *language
core*. I like small, powerful languages... and big, powerful libraries.
    -Olin