Re: Qi Seems Great
- From: pjb@xxxxxxxxxxxxxxxxx (Pascal J. Bourguignon)
- Date: Thu, 30 Apr 2009 00:56:04 +0200
MishoM <mihaylov.mihail@xxxxxxxxx> writes:
On Apr 29, 4:32 pm, Kenneth Tilton <kentil...@xxxxxxxxx> wrote:
I would not put it in terms of quality. Scheme* is perfect and useless,
for example. Common Lisp will simply trounce anything else in the long
run, with all successful ideas popularized by challengers absorbed into
I see your point, but having third party libraries to support the new
ideas come along doesn't mean that the language itself will grow.
Having in mind that the CL standard is rather old, and it seems very
unlikely that a new standard will come soon (or ever), and also having
in mind that there isn't a "de facto standard" set of libraries
(correct me if I'm wrong here), I think that though libraries will be
created to support new ideas as they come along, the CL language (at
least ANSI Common Lisp) itself will not adapt. So, if a new CL
standard (official or not) miraculously appears, it might be better
than what is known as CL now.
What I mean is that in my opinion a language which is based on the
ANSI Common Lisp but extends or modifies the standard does not qualify
as Common Lisp.
What you say here demonstrate a dire lack of understanding of what Lisp is.
Language-wise, Common Lisp is 17 special operators, and an evaluation
model (lambda, closures, environments). This is a very small kernel.
All the rest of the language is defined above this kernel, using macros.
Actually most of the time lisp programmers don't even use the
special operators, but favor instead the macros (eg. dolist or loop
instead of tagbody, setf instead of setq, defun or defmacro instead
of lambda, etc).
And then, some "library" functions to complete it.
The point is that everything above the 17 special operators defined in
the standard has exactly the same status as anything you, as a simple
user of the language, may define. All the libraries have the exact
same status as what is in CL. And this is a lot of stuff, and a lot
of design space to explore for extensions to a programming language.
There's no need to standardize anything there, because it's very easy
to design your libraries to be portable over any CL implementation,
and therefore be a de-facto standard by itself. Each conforming user
library is essentially a CL standard extension. Make it good to have
it used in a lot of applications, and you've got your CL-2009 standard.
There remains the kernel, that you might want to mend with other
concepts. And then either the new concept is orthogonal to the
existing, and can be integrated without difficulty (eg. threads), or
there's some fundamental incompatibility between the new concept and
the existing kernel (eg. full continuations); in this case, you have
to live with the language choices, and your only option is to use
another language, or to work at the metalinguistic level (which is
possible and easy in lisp). In the former case, "customer" pressure
quickly forces the implementations to provide the good features
(eg. threads are now provided in all the implementations, even if some
are not entirely debugged on all the OS yet). And then, even if the
various implementations don't provide a common API, we fall back to
the previous case, where users may develop portability "standard"
libraries (eg. bordeaux-threads becomes THE standard CL thread API, no
need for ANSI or ISO intervention).
Finally, there's no point in "standardizing" a set of library. Each
user may choose what language he uses, composing his language from a
base CL standard, and adding the language libraries he wants.
If you feel a need to define your own new-CL language, well, it's up
to you to specify the set of libraries you need to implement that
new-CL language. You may even write the defpackage "NEW-CL" form to
export all the symbols you want to include in your "standard", and
start to write your applications by using that "NEW-CL" package
instead of "CL". Nothing simpler: (defpackage "MY-APP" (:use "NEW-CL")
....) If your NEW-CL language is good, you might even have a following
and see it become a defacto new "language". (You may even write a CDR).
But since there's no difference in status between CL and NEW-CL (*),
you'll excuse me if I still call it Common Lisp and if I still
consider that CL is not old and dead.
- Re: Qi Seems Great
- From: MishoM
- Re: Qi Seems Great
- Prev by Date: Re: Qi Seems Great
- Next by Date: Re: portable hierarchial packages
- Previous by thread: Re: Qi Seems Great
- Next by thread: Re: Qi Seems Great