Re: Modernizing Common Lisp

From: Frank A. Adrian (fadrian_at_ancar.org)
Date: 05/07/04 

Date: Fri, 07 May 2004 09:45:12 -0700

On Fri, 07 May 2004 15:24:29 +0000, Wade Humeniuk wrote:

> You seem to have some nebulous idea about what is a language standard.
> The CL ANSI specification is a whole different thing than commonly accepted
> libraries.

You seem to be stating that anything that's "in a library" should not have
standard supported bindings. By that argument, file interaction should
not be standardized because it's not part of a language, but accessed
through an API (granted, anyone who's worked with pathnames knows the
horrors of the standardized feature, but...). Nor should memory
management, because raw memory allocation is accessed via an API.

The fact is that OS'es move forward and things that were special case
become commonplace. Models congeal and OS'es support those models. The
fact is that, just as 20 years ago, OS'es had file system models that were
common enough to allow relatively simple abstractions to be built into the
standard, today most OS'es (and Lisp implementations) have threading
models and socket abstractions that are common enough for standardization.

Are you really saying that forcing Lisp programmers to use (relatively)
hard to inject libraries to write portable code is a good thing? Even as
a long time Common Lisp user, I find this to be an annoyance. The bottom
line is that facilities such as UFFI and PORT should be either bound into
shipped CL systems, easily loaded (one "require" statement at most,
without having to load "asdf" or some other crud), or those packages be
used as the starting point for standardization efforts for those
facilities. And, I admit, this is not for any desire for a larger market
share, or larger user base for the language -- it's simply to make it less
of a pain in the ass for me to use these facilities.

So! Why don't I write my own system to do that? Well, to be blunt,
there are already too many systems, all providing access to the same
capabilities, but with incompatible interfaces (sort of like the problem
with all of the Lisp variants around, say, 1978 or so). The point of a
standard is to clear away the clutter to formally say that *this
particular interface* is the way we, as a language community, have decided
to access these features so that we no longer have this particular pain in
the ass. I think there are some features that have progressed to that
point. Perhaps not UI (probably not ever) and perhaps not code dependency
management, but multiprocessing, foreign function interfaces, and socket
interfaces have reached that point, just as file system interfaces had 20
years ago and memory management 40 years ago.

Not standardizing these things at this point is simply a form of software
masochism.

faa

Relevant Pages

  • Re: "Criticism of the C programming language ??????"
    ... "that's not in the standard, ... rewrites of the compiler. ... PH> They got all the compiler vendors to agree to a common ... or graphics libraries or threading libraries, ...
    (comp.lang.c)
  • Re: Dissecting the electorate
    ... interfaces, but I still think the existence of those interfaces should ... the optional libraries that the standard defines ... Common Lisp a few months ago, when I was looking for "a lisp compiler". ...
    (comp.lang.scheme)
  • Re: large files: when ubiquitous?
    ... |> the normal standard POSIX/SUSV3 calls are made, ... |> interfaces that applications see, not interfaces libraries use directly ... Of course if the program calling it uses an unsigned 64-bit value, ...
    (comp.os.linux.development.system)
  • Re: [Lit.] Buffer overruns
    ... It's only a "mountain" by the standard of what's ... evolved by trying various interfaces and changing ... commercial development, organizations with any ... sense did develop libraries better suited to ...
    (sci.crypt)
  • Re: Standard Forth versus Python: a case study
    ... I'm wondering why is so an important mechanism not in the Standard? ... whether that's really a 'different' language. ... Most Forths that run under host OSs have interfaces to their libraries. ... They are not standardized because the systems differ, and the interfaces themselves vary; ...
    (comp.lang.forth)