[Marc Wachowitz]

|   How's the status/development of ISO standardization for Lisp?

according to ISO procedure, there is no development at all at this time,
and very little to be expected before final approval.  after that, the
process is called "technical corrigenda" and "amendments", either of which
options should not be exercised lightly.

ISO/IEC DIS 13816 "Information technology -- Programming languages, their
environments and system software interfaces -- LISP" is under balloting as
an International Standard.  voting began on 1996-05-23 and terminates on
1996-09-23.  during this time, there is to be no activity, except to handle
incoming comments.  after the termination of the voting, negative votes and
other comments must be handled; suggested and required editorial changes
are made; then it is published.  no substantial changes may be made without
a second DIS stage.  this is very, very unlikely.

|   Is there going to be a newer version in near future?

the ISO procedure allows revision of standards every five years.  if errors
are discovered, there is of course room for fixing them.  there is also
room for additions.

I have but one serious gripe with ISO Lisp at this time.  (the body of the
standard uses the name "ISLisp", but the cover reads "LISP", a discrepancy
that must be resolved; I prefer to call it "ISO Lisp" until publication.)

my gripe concerns the special form `dynamic'.  it is used to access a
dynamic variable ("special" in the usual terminology).  (dynamic foo) means
the _dynamic_ variable _foo_.  the setter is (setf (dynamic foo) ...), and
the global defining macro is (defdynamic foo ...).  these are perfectly OK
to me.  however, the `let'-binding is done wrong.  instead of enabling the
programmer to decide whether any given variable is dynamic or not by using
`foo' or `(dynamic foo)' as needed, a special form `dynamic-let' is
introduced.  since the Common Lisp `declare' is not found in ISO Lisp, the
programmer cannot specify the dynamic nature of a variable except through
cumbersome `dynamic-let' forms outside the other binding forms.  if this
had been done right, IMNSHO, `let' and all its friends would take a
"variable name specification" instead of just a name.  (this is akin to
Common Lisp's "function name specification", allowing `foo' and `(setf
foo)' as function names.)  e.g., where ISO Lisp now requires

    (dynamic-let ((foo 1))
      (let ((bar 2))
        ...))

I would like to see

    (let* (((dynamic foo) 1)
           (bar 2))
      ...)

NOTE: there is no `dynamic-let*', so you may have to nest `dynamic-let's to
get the effect of what should have been `dynamic-let*'.

ISO Lisp did away with most of the other binding forms (do, do*, dolist,
dotimes), preferring the more Algol-like looping construct `while', which
_undoubtedly_ will make it more popular with the hordes, so we won't have
the "problem" of introducing `dynamic-do' and friends, but this variant
treatment of the namespace/property/whatever specifier `dynamic' is still
an anomaly that should be fixed.

now, why would I want to have a uniform treatment of something that will be
used only once?  I don't think `dynamic' is the last of the variant forms
or properties of variables we will see.  since ISO Lisp is intended to be
easier in the foreign function interface department than most other Lisps,
(that's how I read it, anyway) it would make sense to use language-specific
properties on the variables.  e.g., if there's a global C variable `gargle',
how does one refer to it?  one way is to provide "indirection" through a
Lisp variable whose references get magically transformed into references to
the global C variable.  another is to make `gargle' a variable of a new and
different kind, and say `(foreign gargle)' just like one would say
`(dynamic gargle)' to refer that other special namespace/property/whatever.

such an open-ended definition of what a "variable name" is would afford
much needed latitude in extending ISO Lisp into special environments and
could have several uses besides language interfaces.  e.g., reading and
writing a memory-mapped I/O register requires a variable to be declared
"volatile" in C, and so does a variable that is shared among processes or
modified by interrupts.  lacking a `declare' mechanism, I think such a
general mechanism would make ISO Lisp succeed in areas where Lisp is now
being disregarded due to prejudice.  such a general mechanism would _also_
allow ISO Lisp to be compiled into other languages that support such things
without loss of expressive power or programmer convenience.

NOTE: ISO Lisp should not attempt define any of these extended variable
forms, but should also not prohibit their addition by an implementation
that needs them, such as it does by defining an entirely new and non-
orthogonal `dynamic-let' form.

(not that I'm anywhere near _happy_ with `while' and `for'.)

How's the status/development of ISO standardization for Lisp? In
/pub/lisp/islisp/README on ma2s2.mathematik.uni-karlsruhe.de, it
says:

[For those who didn't know: No, this is not ANSI Common Lisp, but
 much smaller.]

What this establishes is that there is no reason for gratuitous ISLisp/
Scheme incompatibility on the grounds of ease of foreign interfacing.

[Richard A. O'Keefe]

|   Not only is it smaller, it is *gratuitously* different from some other
|   important Lisps, including Scheme, EU-Lisp, and Common Lisp.  I hope it
|   dies.

maybe you could sum up the differences?  I meant to, a while ago, but the
whole language leaves me with an icky feeling, partly because it feels like
somebody had to compromise with somebody from Bell Labs or something.  but,
hey, maybe the reason other Lisps "failed" was precisely that they didn't
have iteration constructs called `while' and `for'.  such things are hard
to tell.

however, the class system appears solidly and well designed.

In article <4t225m...@goanna.cs.rmit.edu.au> o...@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

   From: o...@goanna.cs.rmit.edu.au (Richard A. O'Keefe)
   Newsgroups: comp.lang.lisp
   Date: 23 Jul 1996 18:23:18 +1000
   Organization: Comp Sci, RMIT, Melbourne, Australia
   Lines: 13
   References: <4t0b6d$...@trumpet.uni-mannheim.de>
   NNTP-Posting-Host: goanna.cs.rmit.edu.au
   NNTP-Posting-User: ok
   X-Newsreader: NN version 6.5.0 #0 (NOV)

   m...@ipx2.rz.uni-mannheim.de (Marc Wachowitz) writes:

   >How's the status/development of ISO standardization for Lisp?
   >[For those who didn't know: No, this is not ANSI Common Lisp, but
   > much smaller.]

   Not only is it smaller, it is *gratuitously* different from some other
   important Lisps, including Scheme, EU-Lisp, and Common Lisp.  I hope it
   dies.

I kinda second that.  If there is something we do not need is yet
another incompatible Lisp.

[Erik Naggum]

|   (not that I'm anywhere near _happy_ with `while' and `for'.)

[Marc Wachowitz]

|   I guess they are for programmers who don't trust their implementation
|   about a decent optimization of recursion - not too unrealistic if one
|   expects the language to be used not only in the form of compiling to
|   machine code, but also as a simple scripting/extension language for
|   applications.

I was referring to the gratuitous renaming of `do' in the case of `for'.  I
happen to like `loop' for a number of applications, but find `while' to be
an oddly un-Lisp-like name.  such little things distract me because they
are so do devoid of value that one wonders why they bothered.

[disliking "dynamic-let"]

[Richard A. O'Keefe]

|   I don't think the ease of calling C functions from Sun's ESH can be beaten.
|   If I read the (somewhat patchy) documentation, this even extends to C++.
|   Step 1:     slurp the appropriate header using "ix"
|   Step 2: load the Scheme file written by "ix"
|   Step 3: you're away laughing.

you realize, of course, that this can be true for any product and any
language, regardless of how much work this "ix" thingy does.

|   What this establishes is that there is no reason for gratuitous ISLisp/
|   Scheme incompatibility on the grounds of ease of foreign interfacing.

non sequitur.  unless you're in the business of selling "ix"'es or "esh"'es.

|   ESH provides this via a borrowing (without acknowledgement) of the old
|   Pop-2 idea of "updaters".  Again, it's an *extension* to Scheme, with a
|   proven record of working extremely well in practice since the '60s,
|   that doesn't need to break existing code.

the issue is that ISO Lisp has opted for a notation for dynamic variables
that differs significantly from the traditional way to declare special
properties on variables, and has not done so consistently or open-endedly.

I actually fail to see what ESH is doing in here at all, unless it has been
a major influence on the design of ISO Lisp, which I sort of doubt.

Looking at the existing variants, there's still no clean and "state of
the art" Lisp. Scheme is a relatively clean base, at least has hygienic
macros, but it's not object-oriented nor does it have separate compilation
with name spaces. EuLisp might come close, but its macros are dirty
(last time I looked; it has been version 0.99 for some time now). Common
Lisp is mostly a large, complicated assembly of features, and lacks
hygienic macros, too. Dylan is quite close, too - though unfortunatley,
it deviated from the one and only true syntax for Lisp ;-)

[Note the above isn't meant to belittle the designers of the various
 variants, but to allude in a few words why one may still see a need for
 another Lisp - though ISO Lisp doesn't appear to fill that gap either.]

[Kent Pitman]

|   I think you meant "apparent" value.  The rest of this message is what
|   you get for leaving out little words like that. ;-)

and had I not left it out I would have lost the opportunity to read your
excellent explanations and thus understand part of the rationale...

thanks for taking the time to explain it.

SERIOUSLY, THOUGH, I think sometimes people don't see the thought
behind the decisions and do suppose them to be random and unmotivated,
but I hope to show that this is not so.  I think these names are
neither gratuitous nor devoid of value, but I can see what might lead
you to think they were and I hope you'll indulge me in a chance to
change your mind.

First, the ISLISP language specification, by its own admission, is a
political compromise to unify the common elements of several major
dialects, most notably Common Lisp, EuLisp, LeLisp, and Scheme
(alphabetically mentioned, I hasten to add).  So whether you see a
chosen as a "renaming" or a "new introduction" is a matter of
perspective and was, in each case, a matter we discussed carefully.

And, philosophically, even if you are following just one dialect, if
you both rename and change the meaning of something, I have emotional
trouble with calling that a renaming; I call it an introduction.  For
example, if someone proposed replacing CL's DO with ISLISP's FOR, I
would not call that a renaming.  You'll see why if you read on.

My after-the-fact sense is that we (WG16) attempted, not as a matter
of explicit policy, but in my opinion as a matter of observed
practice, in all reasonable cases to choose names NOT present in any
of these dialects for names that would not have the semantics already
present in those dialects because our aim was not to force a great
deal of unproductive forced change in those dialects.  The hope was to
choose names that could compatibly co-reside with existing tools where
such need existed.  Of course, in situations where module and/or
package systems exist (which is most, even though such facilities are
not presently described by ISLISP), renaming of the operators involved
is probably possible so the names given by ISO are not something cast
in concrete (as a matter of practice).

In the particular case you cite of DO, the ISLISP version, FOR, does
not has neither a tagbody nor an implicit NIL block.  The tagbody is
no major matter, I suspect, since errors where the programmer thought
there was a tagbody but there was not would nearly always be
recognized by the compiler in any situation I can imagine.  But in
mixed ISLISP and CL code, the confusion over where:

  (BLOCK NIL
    (DO (...) (...) (RETURN ...))
    ... more stuff ...)

returns would not and in fact could not be mechanically dectected by a
compiler, since this is legitimate CL code and would have been legit
ISLISP code, but the return points would have been different (had
ISLISP used the name DO instead of FOR): for CL it would have been the
DO, and for ISLISP it would have been the BLOCK (and execution of
`...more stuff...' would have been bypassed).

I recall that I personally asked the WG16 committee and they readily
agreed to rename DO to FOR exactly so that CL programmers would not be
perturbed by the apparent incompatibility of ISLISP.  If nothing else,
it would make in-person conversation about "DO" or "FOR" unnecessarily
complicated because package/module designations would be required
verbally to assure everyone was talking about the same thing.

Incidentally, the name LOOP was rejected for similar reasons.  It
would have caused a major religious war over the semantics of LOOP and
would have wrongly hinted a decision on the part of the ISLISP group
that CL-style LOOP should be `put mercilously to death'.

We did discuss briefly the idea of just having (LOOP form*) but that
would have required LOOP to establish a return point, and would have
gotten into the question of whether the return point should be named,
and why should it be named NIL.  If there were no return point, an
explicit BLOCK would always be neeeded and you'd have a problem like
the one I described above.  Some representatives really disliked the
idea of a special block name, so we were stuck with incompatible
semantics as a given, and so we opted for a new name instead of
clobbering some existing dialect's name.

Note, for example, that only RETURN-FROM is present and not RETURN.
In a new dialect with no compatibility constraints, we probably would
have called that operator just RETURN, avoiding the need for a long
name.  But we were mindful of the problems the incompatible naming
could cause, so we opted not to `simplify' things in that way.

Returning to the notion of putting LOOP to a merciful death, btw, I
should say that certainly there are those (and I am on some days among
them) who think as a personal matter that this would be good or right
or fun or deserved.  But my job on the WG16 committee was to represent
my country (not even just my company, and certainly not my individual
preferences).  And my country believes, as a matter of voted practice
(through X3J13 and ANSI CL) that CL-style LOOP is sufficiently useful
that it should be allowed to stand in those places where it is in wide
use, which is really a lot.

Others on the committee may have had similar personal preferences with
regard to LOOP and others, but always in the end my sense is that we
came to the conclusion that destabilizing the established Lisp
community to push our personal aesthetic ends would be a bad choice.

In the end, after much sparring, we tried to opt for tolerance and
respect for the existing cultures and systems and dialects, rather
than for having one community win and another lose... or, if done
badly and piecemeal, having one community win on one little operator
skirmish and another on another little skirmish, but in the end having
the value of each language we sought to unify decimated, and really
having all of us lose.

I didn't really address WHILE because my recollection is fuzzier on
that.  It was either chosen for reasons like thos above or because it
was in one of those dialects I mentioned with appropriate semantics
such that we were able to use the name directly.

So there you have it.  You might or might not accept these design
choices as ones you personally would have made, but I hope you will
accept that this was not simply a "gratuitous" change made by a set of
people trying to pick fun names in isolation.  That's a game that I
agree could go on forever, and I agree it doesn't go anywhere. I see
the purpose of standards as being to build a bridge between
communities and to create common terminology that people can accept
and use to better their work, rather than to injure it.  And this was
the best we could reasonably come up with under the circumstances of
the time, given the resources we had to allocate to the task.

As a footnote, I'll just note that had we picked the name DO instead
of FOR for the iteration construct you cite, we'd have been open to
much more deserved criticism from the CL community about "gratuitous"
incompatibility.  So one way to see the outcome is as our having made
a choice between suffering the ire of those who think the names are
gratuitous and those who think the semantics are gratuitous.  A hard
choice maybe, but I'm comfortable that we made good choices under what
were really some very difficult working constraints.

 --Kent Pitman
   k...@harlequin.com

[Roly Perera]

|   Can someone explain what 'ISO Lisp' is?  Is it 'ISO' as in
|   'International Standard'?  If so I didn't realise such a standard
|   existed.  (I know Common Lisp became an ANSI standard back in 1994.)

ISO DIS 13816 Information technology -- Programming languages, their
environments and system software interaces -- LISP.

it's only 127 normative pages.  voting on it terminates 1996-09-23.  talk
to the BSI (British Standards Institute) about getting a review copy and
offer your reasons for rejecting or approving it.

   [Roly Perera]

   |   Can someone explain what 'ISO Lisp' is?  Is it 'ISO' as in
   |   'International Standard'?  If so I didn't realise such a standard
   |   existed.  (I know Common Lisp became an ANSI standard back in 1994.)

   ISO DIS 13816 Information technology -- Programming languages, their
   environments and system software interaces -- LISP.

   it's only 127 normative pages.  voting on it terminates 1996-09-23.  talk
   to the BSI (British Standards Institute) about getting a review copy and
   offer your reasons for rejecting or approving it.

I am sorry to be so draconian. I won't be able to vote because of
time constraints, but I still think that there is one very good reason
for rejecting the standard.  Nobody needs it.

[Erik Naggum]

|   ISO DIS 13816 Information technology -- Programming languages, their
|   environments and system software interaces -- LISP.

FWIW: in a letter dated 1996-07-18, ISO/IEC renames DIS 13816 "ISLISP".

In article <s08afwhviu7....@lox.icsi.berkeley.edu>,

[Barry Margolin]

|   Note that rejecting the standard is not one of the options on the
|   ballot.

technically true, but irreconcilable comments do, in fact, constitute
rejection.  recall that the DIS stage may be the first opportunity a
national body has to comment on a standard.

|   By virtue of the fact that they approved the DIS in the first place,
|   it's effectively a done deal that there will be an ISO ISLISP standard;
|   only small details can be changed at this point.

who are "they"?  CD->DIS is approved by P-members at the SC level.  DIS->IS
is approved by P-members at the TC level.  16 P-members of SC 22 approved
of DIS 13816.  that's not enough to carry it forward if the rest reject it.

conclusion: there is ample room for rejection of ISLISP.

voting on DIS 13816 terminates on 1996-09-23.