Re: Qi Seems Great

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
The Ball.nd

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.

--
__Pascal Bourguignon__
.

Relevant Pages

  • Re: How Common Lisp sucks
    ... necessities in today's world. ... getting acceptance of a considerable number of members in the Common Lisp community. ... Now you are apparently invoking a defacto standard. ... If we don't find a single example for changing the language in a fundamental way that would actually make the language easier to understand for newbies without loosing expressiveness, ...
    (comp.lang.lisp)
  • Re: How Common Lisp sucks
    ... in the Common Lisp community. ... libraries that work across implementations that provide de facto ... This is one of the very few instances of behavior outside the standard ... to the language at all. ...
    (comp.lang.lisp)
  • Re: Can Your Programming Language Do This?
    ... Common Lisp is a programmable programming language. ... gains of the large CL standard over the smaller Scheme standard was ... not having some standard (libraries) for some task implies not having ...
    (comp.lang.lisp)
  • Re: Qi Seems Great
    ... Common Lisp will simply trounce anything else in the long ... ideas come along doesn't mean that the language itself will grow. ... Having in mind that the CL standard is rather old, ... , I think that though libraries will be ...
    (comp.lang.lisp)
  • Re: read and write
    ... the C standard says otherwise. ... which are also not a part of the language. ... of these libraries are part of "C", whatever it is, since they contain ... However, any hosted implementation is required to include the entire standard C library, and prior to the standard the first edition of K&R says "Chapter 7 describes the standard C I/O library, which provides a common interface to the operating system. ...
    (comp.lang.c)