Re: Can Your Programming Language Do This?

On 4722 September 1993, joswig@xxxxxxxxxxxxxxxxxxxxxxx wrote:
Common Lisp standard has not been updated to contain new concept found
by others language.

Mostly it does not need to. You can update Common Lisp yourself.
Common Lisp is a programmable programming language.
You need a new feature? Add it.

I think this argument is not a good one at all, at least if you
consider that CLers have routinely pointed out that one of the major
gains of the large CL standard over the smaller Scheme standard was
that the most commonly used functionality does not need to be
implemented times and times again and incompatible to each other.

it could be nice. If you are going to follow the standard convention of
language, why not have your compiler know about it too?

Because it would limit you in naming. Common Lisp does not limit you.
Especially you can embed different languages with different
naming standards in Lisp easily.

So what? I really don't see the problem here. I find the idea of
warning wrt. naming conventions quite appealing. That one might want
user-level customizability of what to warn about seems like an
additional level of complexity but not impossible to me.

[LOOP] [...]
Pathnames in Common Lisp are just a hack.

I think some of the functionality of CL could be removed from some
"kernel" standard and moved to some "standard library" part. Note that
not having some standard (libraries) for some task implies not having
standard solutions for some tasks that *are* standard problems (like
interfacing to C-code, database access etc.). There has been much
debate on cll on the question if libraries do need to be standarized
or not, with somebody (Kent I think) pointing out that maybe de facto
standards by popularity might be all there needs to be. But ...

There are many more reasons and restrictions on what to put
in a standard. See also the goals that people wanted to achieve
with Common Lisp and see also the interests of the various
involved groups (users, implementors, vendors, developers, ...).

For example, imagine how hard would it be if someone ask in a news
groups and your answer cannot contains format, loop, map, assoc,
destructring-bind, etc. because it does not exist as a standard and the
de facto version has some variance in it between each implementation.

Yes, so we have some version of these functionalities. They may
not show the best design, but the best we got standardized.

I wouldn't take that lightly as it implies that a quite large group of
people actually *did* compromise on something that both seemed
worthwile and possible to everybody in this large group.[1] This is
quite a different situation from the one in which everybody uses one
particular library because its the only functioning *implemented*
solution around. I.e., having one popular de facto library around does
not imply it is really the "best" (on whatever matrix) for the task at
hand.

But perhaps I'm just to rash and should rather wait another five
years. CL has gone quite a bit of way in the last five years and it
doesn't seem to have stopped recently.

Holger


Footnotes:
[1] Perhaps it's just my impression from reading too much cll, but
for some of the more popular libraries on the net, I would grant the
label "wide-spread reception" only to CL-PPCRE. For CLSQL, I think
that there are too much quirks in its API (there is either to few or
too much functionality) and for FFI, well there are at least to
competing libraries. Not to mention the horrendous set of "solutions"
for web programming.


--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"Gut, daß es öffentlich-rechtliche Software gibt, die nach 20.00 Uhr
keine Werbung mehr anzeigt."
-- Matthias Warkus in de.comp.os.unix.linux.misc
.

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)