Re: Running Standalone Lisp Programs

From: Christopher C. Stacy (cstacy_at_news.dtpq.com)
Date: 11/02/04 

Date: Tue, 02 Nov 2004 04:28:36 GMT

tar@sevak.isi.edu (Thomas A. Russ) writes:

> cstacy@news.dtpq.com (Christopher C. Stacy) writes:
>
> > M Jared Finder <jared@hpalace.com> writes:
> > > However, just because something is easy to write, doesn't mean that it
> > > shouldn't be in a standard library. NTH is easy to write, but it
> > > still is in the standard library.
> >
> > NTH is applicable to all platforms where Common Lisp ran in the past,
> > runs today, and will run in the future; but the same cannot be
> > said for a command-line interface (even for just "today").
> > That's why it's not there; this has been explained several times.
>
> I can understand the general philosophy of this, but it seems that
> perhaps some sort of interface to "program parameters" would not be a
> bad thing to have in the language. On platforms without a command line
> interface, one could imagine that vendors could create a different way
> of specifying and supplying such parameters.
>
> Presumably such an interface might take the form of an ALIST or
> other structure which associates keys with values.

While I believe that there are some things that could be improved
in the standard, it cannot be underestimated that adopting a feature
into the ANSI Common Lisp standard is a very problematic venture.
The political, technical, and financial implications are enormous.
I don't think that most people comprehend what it means to invoke
the ANSI mechanism. Because of that, and for longevity and quality,
I believe the "core language" standard should be limited to universally
applicable solutions. Given our accumulated experience,
I think that this criteria should be even more stringent
than it was the first time around.

In many cases, a better route would be a standard library.
I sense some reluctance to this concept -- what's the problem?

Command-line arguments were considered in the design of Common Lisp.
I remember raising the related issue of returning values to the
operating system (eg. an "exit status code"), even though my
primary platform (LispM) did not have that concept.

Of course, there are also many more environment-related features
that we could talk about. Unlike command-line arguments, some of
these other things (like network sockets and multiprocessing) have
serious technical implications for the vendors of implementations.
Let's see how far we can get with this fairly trivial one first.

We knew more about command-line arguments back then than most
programmers do today. Here are some things that we know today
about command-line arguments and ANSI Common Lisp:

1. The lack of these features in the language hasn't stopped
   anybody from writing Common Lisp programs in the past couple
   of decades, and did not even stop a newbie last week.
   People even write portable programs that do this.

2. Some people would like a standard interface for this.
   I don't know of anybody who disagrees, although some
   people feel that it does not need to part of the core
   language defined by the ANSI standard.

3. There are many different ways they are specified.
   Without specifying something vastly grander, the key
   and value objects would be necessarily platform-dependant
   and therefore unspecified in nature.

4. Commond-line arguments were arguably more important on
   those older systems 20-30 years ago, and are still used
   sometimes on major systems today. They are increasingly
   inapplicable to even more modern platforms: GUI-based
   workstations and portable computers, mobile phones and
   other "embedded" computers, robots, network-oriented
   applications (HTTP/XML/SOAP services, agents), etc.

5. Standard libraries for ANSI Common Lisp have been very
   successful recently, with lots of user contributions
   and vendor cooperation.

Let's have people propose exactly what they would like for
a command-line API, in the form of a portable reference
implementation. The result can be proposed as a standard
library that we might adopt.

> There are certainly other functions that are in the standard that are
> not really applicable to all potential platforms. Certain embedded
> processors don't have file systems, but that wouldn't be a good argument
> for not including file system operations in the CL standard.
>
> In fact, I think that the lack of a DIRECTORY-P predicate for pathnames
> is a real weakness of the standard. It makes it impossible to write a
> portable file system traversal within standard Common Lisp.

I very much agree that The file/pathname system is a serious wart
in ANSI Common Lisp, because it is so incomplete and underspecified
as to be worse than useless.

It is an illustration of the problems with adding such features to
the language. Although The pathname and file system features was
an entirely and beautifully solved technical issue at the time,
the politics did not allow for its inclusion in the standard.
Instead, we got a pile of insufficient crap adopted in its place.

Whether including these features in the core language should be
considered to have been a misttake is a question that is loaded.
The reality is, the legacy of this is that to really be able to
fully portable ANSI Common Lisp programs that use the file system,
users have had to implement their own multi-platform libraries.
Some people have written more, and some less, and there is no
standard library that everyone uses.

So I don't see file/pathname system features as a positive
recommendation of why command-line arguments ought to be part
of the ANSI language standard.

(I feel as though everything I've said in this message is
just the same old song that I've been singing over and over,
but perhaps I've was using too much shorthand and not getting
my points across.)

cheers,
Chris

Relevant Pages

  • Re: DIRECTORY behavior with /= implementations
    ... each file system is implementation-defined ... fuzzy wording meant. ... the standard went out. ... platforms where there were multiple implementations actually needed ...
    (comp.lang.lisp)
  • Re: Comparing Lisp conditions to Java Exceptions
    ... post came across very critical of Common Lisp (that is, ... > to be explicit on this and there was no money to do that project. ... > when you don't see something in the formal standard written and ... No reason why I won't try to do so in the future. ...
    (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: Qi Seems Great
    ... Common Lisp will simply trounce anything else in the long ... 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, ...
    (comp.lang.lisp)
  • Re: scheme seems neater
    ... people are not interested in extending Common Lisp? ... ANSI CL standard is, for example, a system definition facility. ... the fact that a hygienic macro system doesn't exist for Common ... implementations of syntax-rules bug-free? ...
    (comp.lang.lisp)