IS(O-)Lisp status?
Erik Naggum
[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'.)
#\Erik
Marc Wachowitz
How's the status/development of ISO standardization for Lisp? In
/pub/lisp/islisp/README on ma2s2.mathematik.uni-karlsruhe.de, it
says:
> This directory contains the ISO Lisp draft, as submitted to SC-22.
> Status of ISO Lisp normalization: Shall be DIS (Draft International Standard)
> in April 1996, says the time-table.
The latest version to be found there is islisp-15.6, dating from
11-Sep-1995; which changes (if any) are to be expected (I hope
some kind of module/package system will be added)? Is there going
to be a newer version in near future?
[For those who didn't know: No, this is not ANSI Common Lisp, but
much smaller.]
-- Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de>
Richard A. O'Keefe
Erik Naggum <er...@naggum.no> writes:
>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.
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.
What this establishes is that there is no reason for gratuitous ISLisp/
Scheme incompatibility on the grounds of ease of foreign interfacing.
>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.
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.
--
Fifty years of programming language research, and we end up with C++ ???
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.
Richard A. O'Keefe
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.
Erik Naggum
[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.
#\Erik
Marco Antoniotti
In article <4t225m$i...@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$g...@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.
--
Marco Antoniotti - Resistente Umano
===============================================================================
International Computer Science Institute | mar...@icsi.berkeley.edu
1947 Center STR, Suite 600 | tel. +1 (510) 643 9153
Berkeley, CA, 94704-1198, USA | +1 (510) 642 4274 x149
===============================================================================
...it is simplicity that is difficult to make.
...e` la semplicita` che e` difficile a farsi.
Bertholdt Brecht
Erik Naggum
[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.
#\Erik
Marc Wachowitz
Erik Naggum (er...@naggum.no) wrote:
> | Is there going to be a newer version in near future?
>
> the ISO procedure allows revision of standards every five years.
What I meant is whether the mentioned document version is the final one,
except the trivial corrections; since nobody mentioned changes, I guess
that's the case. Such changes appeared likely to me, since the previous
drafts had a module system, and the current version doesn't have them.
IMO, that's really bad. Also, the statement about what a macro can or
can't do would need much more precision, IMO - it's somewhat funny to see
many front pages with definitions etc., but only a few words on such a
relatively complicated topic.
[disliking "dynamic-let"]
> if this had been done right, IMNSHO, `let' and all its friends would take a
> "variable name specification" instead of just a name. [...]
> I would like to see
>
> (let* (((dynamic foo) 1)
> (bar 2))
> ...)
Of course, using macros, you can invent your own "one for all" binding
form, even mixing functions and variables, if you prefer that ;-) Given
unwind-protect, having built-in dynamic variables is merely a matter of
portability and optimization in simple implementations, anyway.
> 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.
Why not simply use accessor/modifier functions for non-standard "places",
and leave the standard variable notation alone for one and only one thing,
i.e. Lisp variables? I'd prefer that anyway for maintenance reasons, but
it also preserves clarity about what can induce "stange effects" and what
can't. [Since foreign functions, volatile data etc. require some specific
cooperation from the code generator anyway, this doesn't imply any function
call overhead.]
> (not that I'm anywhere near _happy_ with `while' and `for'.)
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.
-- Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de>
Erik Naggum
[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.
#\Erik
Howard R. Stearns
Erik Naggum wrote:
>
> [Erik Naggum]
>
> | (not that I'm anywhere near _happy_ with `while' and `for'.)
>
>
> | 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.
>
> 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.
>
> #\Erik
I was under the impression that the idea was to preserve coexistence
with Common Lisp by introducing a name change for any feature which was
not syntactically and semantically identical between the two languages.
Thus the names changes aren't gratuitious. However:
1. I don't know if this is true. Kent? Anybody?
2. Why not use the package system to accomplish that?
Marc Wachowitz
Marco Antoniotti (mar...@salmon.icsi.berkeley.edu) wrote:
> In article <4t225m$i...@goanna.cs.rmit.edu.au>
> o...@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
> 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.
Incompatible to what? ;-) Each of the existing ones is quite different
from the others, and none could reasonably be seen as THE Lisp, IMO.
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.]
-- Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de>
Erik Naggum
[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.
#\Erik
Kent Pitman
> 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.
I think you meant "apparent" value. The rest of this message is what
you get for leaving out little words like that. ;-)
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
Disclaimer: My remarks here are personal recollections, opinions,
and analysis and do not necessarily represent the official views
of SC22/WG16 (ISO's ISLISP working group), X3J13 (ANSI's Common
Lisp subcommitee), or my company (Harlequin).
Roly Perera
> > 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.
>
> Incompatible to what? ;-) Each of the existing ones is quite different
> from the others, and none could reasonably be seen as THE Lisp, IMO.
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.)
Roly Perera
----
Interactive Computers Ltd
3 Cumberland Road
Acton
London W3 6EX
Phone: +44 (956) 414 395
Phax: +44 (181) 932 2490
Email: ro...@private.nethead.co.uk
----
Erik Naggum
[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.
#\Erik
Marco Antoniotti
In article <30476519...@arcana.naggum.no> Erik Naggum <er...@naggum.no> writes:
[Roly Perera]
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.
Cheers
Erik Naggum
[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".
#\Erik
Barry Margolin
In article <s08afwh...@lox.icsi.berkeley.edu>,
Marco Antoniotti <mar...@lox.icsi.berkeley.edu> wrote:
>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.
Note that rejecting the standard is not one of the options on the ballot.
A country can vote No, but they must accompany a no vote with a list of
changes that would need to be made to the DIS that would cause them to
change their vote to Yes. If their complaint is that ISLISP is different
from (say) Common Lisp, I suppose they could submit the entire CL standard
(1300 pages) with their vote, but I don't think this would be considered
appropriate. 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.
--
Barry Margolin
BBN Planet, Cambridge, MA
bar...@bbnplanet.com - Phone (617) 873-3126 - Fax (617) 873-6351
(BBN customers, please call (800) 632-7638 option 1 for support)
Erik Naggum
[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.
#\Erik