If you want X, you know where to find it (was Re: do...until wisdom needed...)

[Douglas Alan]

"Andrew Dalke" <dalke at acm.org> writes:

> >See Guy Steele, "Growing a Language":

> http://cm.bell-labs.com/cm/cs/who/wadler/gj/Documents/steele-oopsla98.pdf

> >"We need to put tools for language growth in the hands of the users"

> That tools is the C (or Java) implementation, no?  Otherwise growth
> into forms like Stackless and Alice never would have taken place.

That's a good thing too, but Steele is specifically talking about
in-language extensibility.

> > There are numerous reasons.  The fact that the others are not
> > widely used, are not tuned for scripting, do not have as elegant a
> > syntax, are not as easy to learn, are not available on every
> > platform known to man, do not start up in a fraction of a second,
> > do not come with a huge library of useful tools, etc., are all
> > salient reasons.  And yet there remain others.

> How does this jibe with your statement that Lisp
>    "even though it was invented in the '50's, ... remains
>     today one of the most modern of languages."

It's a very modern language (more modern in some ways than Python,
multimethods and a sophisticated meta-object protocol being examples
of two very modern features that it supports), but the Lisp designers
went in two different directions, neither of which was the right thing
to do to achieve world domination.  This is one of the tragedies of
the ages, if you ask me.  Half of the Lisp folk went and did Common
Lisp.  The market for this was people who want to spend lots of money
on big bloated developments systems that rub your back and massage
your feet while you are programming.  The other half went off and did
Scheme, laboring hard on making a language so small and simple and
pure and clean that no one would ever use it for anything real.  Both
halfs thus relegated their lovely works to ghettos -- the Common Lisp
folk the A.I. ghetto and the Scheme folk to the academic/functional
programming ghetto.  Lisp also has a funny syntax that give some
people indigestion.  It looks like this:

   (defmethod (fifo :DEQUEUE) ()
     (if (null (cddr fifo-list))
	 (error 'fifo-empty)
	 (prog1 (cadr fifo-list)
		(setf (cdr fifo-list)
		      (cddr fifo-list))
		(if (null (cddr fifo-list))
		    (setq end fifo-list)))))


The chance of reviving Lisp into a mainstream language at this point
seems remote, but that doesn't mean that it can't be raided for some
of the incredible ideas that it embodies.

> Does this mean with 40+ years of development, Lisp does not have
> features of some modern language, in that it isn't widely
> used, not tuned, etc.?

No one ever did a version of Lisp that was highly tuned for scripting.
Unless you were running on a Lisp Machine, that is, but they were
rather expensive and they didn't sell many.  That doesn't mean Lisp
isn't a modern language.  It means that Lisp stuck to its core
audience of A.I. researchers.

There is something called "The Scheme Shell", which was a version of
Scheme that was supposed to be good for scripting, but the last time I
looked at it it took too long to start up to really be good for
scripting.  This is not an inherent problem with Scheme -- it just
wasn't an ideal implementation.

> > For instance, if I had procedural macros, I wouldn't need to bug
> > the language implementers to add variable declarations -- I could
> > do it myself.

> In my limited understanding of hygenic macros, wouldn't you only
> be able to apply macros to a sufficiently Python-like language,
> in order to transform it internally to a Python representation?

> That is, you couldn't use hygenic macros to convert Pascal
> code into Python.  (Is that what the 'hygenic' part means?)

Well, yes, you could use a procedural macro (hygienic, or otherwise)
to convert Pascal code to Python, but it would be one really big hairy
macro, and I don't think that be a good idea.  More modestly, you
might define two macros, "let" and "set" so that

   let x = 3

gets translated into

   try:
      x
      raise VariableAlreadyBound("x")
   except NameError:
      x = 3  

and

   set x = 3

gets tranlated into

   try:
     x
     x = 3
   except NameError:
      raise VariableNotBound("x")

More later.

|>oug