comp.lang.lisp vs. comp.lang.scheme
Klaus Schilling
Scheme is by many people viewed as some dialect of Lisp. Alas it has its own
newsgroup (comp.lang.scheme).
When does it make sense to crosspost to both groups ?
Klaus Schilling
Rainer Joswig
<Klaus.S...@home.ivm.de> wrote:
> Scheme is by many people viewed as some dialect of Lisp.
Does anybody think it is not a dialect of Lisp? Really?
Abelson/Sussman: "Scheme, the dialect of Lisp we use..."
Alan Perlis: "Lisp changes. The Scheme dialect used in this text..."
> Alas it has its own
> newsgroup (comp.lang.scheme).
>
> When does it make sense to crosspost to both groups ?
In case you have a posting interesting to both camps?!
Specific questions about the Scheme dialect or its implementations
are better posted to comp.lang.scheme.
comp.lang.lisp is also the home of Common Lisp users/vendors.
They simply don't have a newsgroup of their own
(no comp.lang.common-lisp). Same for users
of Standard Lisp, EuLisp, ISLisp, ...
Some directly related newsgroups:
Lisp in general
comp.lang.lisp - Everything about Lisp.
comp.std.lisp - For discussion about standardization.
comp.org.lisp-users - Lisp users, unite!
Dialects, implementations and related languages
comp.lang.clos - The Common Lisp Object System.
comp.lang.lisp.franz - Franz Lisp.
comp.lang.lisp.mcl - For users of Macintosh Common Lisp.
comp.lang.lisp.x - XLisp.
comp.lang.scheme - The Scheme dialect of Lisp.
comp.lang.scheme.c
comp.lang.scheme.scsh - The Scheme Shell.
comp.lang.dylan - The Dylan programming language.
comp.lang.logo - The Logo programming language.
Lisp Machines
comp.sys.xerox - Sometimes Xerox Lisp machines are for sale.
comp.sys.ti.explorer - The TI Explorer Lisp machine. Not about
pocket calculators.
info.slug - For users of Symbolics Lisp machines. Get one if you can.
Software
comp.windows.garnet - The Garnet UIMS.
comp.text.interleaf - Interleaf's publishing solution, extensible
with Lisp.
comp.emacs - The famous editor.
comp.emacs.xemacs - An emacs variant.
comp.cad.autocad - Some AutoCAD versions are programmable in AutoLisp.
comp.text.interleaf - Interleaf's publishing solution, extensible
with Lisp.
A little more remotely:
Dialects, implementations and related languages
comp.sys.newton.programmer - NewtonScript and more.
Programming Paradigms
comp.lang.functional - Functional Programming.
comp.object - Object-oriented Programming.
comp.object.logic - Combining OOP and Logic Programming.
Software
comp.ai.shells - Various AI shells.
sci.math.symbolic - Some of the leading Computer Algebra programs
are written in Lisp
(Reduce, Macsyma, Axiom, ...).
Greetings,
Rainer Joswig
Michael Tuchman
the same message twice - once in comp.lang.lisp and once in comp.lang.scheme.
Those who have anti-crossposting filters on their newsgroups won't read it at
all :-)
Klaus Schilling wrote:
> Scheme is by many people viewed as some dialect of Lisp. Alas it has its own
> newsgroup (comp.lang.scheme).
>
> When does it make sense to crosspost to both groups ?
>
rarely, if ever.
> Klaus Schilling
Kent M Pitman
> Scheme is by many people viewed as some dialect of Lisp.
FWIW, not by me.
Don't let the parens fool you. There are a number of really key
differences between Lisp and Scheme that are just as major as between
languages in the Algol family.
See also my paper "Lambda, the Ultimate Politica Party" from
Lisp Pointers, now at http://world.std.com/~pitman/PS/Lambda.html
> Alas it has its own newsgroup (comp.lang.scheme).
I would have said "Thank goodness". It's not that I'm trying to say
Scheme is junk. I'm just trying to say "everything in its own place".
Scheme and Common Lisp, as communities, do not value the same things.
Scheme and Common Lisp, as languages, do not provide the same things.
Scheme and Common Lisp people do not think about or do things the same way.
Scheme and Common Lisp do not attract the same people.
Consequently, separate newsgroups seem entirely appropriate to avoid
endless debate over issues which come down to mere personaly preference
and would never usefully be resolved if we had to pick one or the other
solution.
The good thing about a multicultural world is that there are is a
place for everyone--and NOT always the same one. The bane of a
multicultural world is people thinking acceptance of multiculturalism
means putting everyone in one room and forcing them to agree.
> When does it make sense to crosspost to both groups ?
For my money, as seldom as possible. I have explained the numerous reasons
why I think cross-posting is a disaster always to be avoided in the following
location, so I don't have to keep repeating myself:
Rainer Joswig
<pit...@world.std.com> wrote:
> Don't let the parens fool you. There are a number of really key
> differences between Lisp and Scheme that are just as major as between
> languages in the Algol family.
There are a lot of differences in actual Scheme systems.
Some try to copy things from Common Lisp
(CLOS, exceptions, ...), some try to be minimal but with
compromises (like SIOD), some are large (MIT Scheme),
some add shell capabilities (SCSH), some are more
like thought experiments, ...
Well, and the there are the "standards"...
> Scheme and Common Lisp, as communities, do not value the same things.
> Scheme and Common Lisp, as languages, do not provide the same things.
> Scheme and Common Lisp people do not think about or do things the same way.
> Scheme and Common Lisp do not attract the same people.
Same is true for Scheme A and Scheme B, IMHO.
Kent M Pitman
> BTW, could someone say a couple of words about islisp?
> like:
> - when is the standard expected to be finished? (estimates)
It's been done for a while.
> - how is it supposed to differ from ANSI CL?
It's tiny. It's not an ANSI CL subset. It's not a Scheme subset.
It's not a Eulisp subset. It is, alas, new design by committee yet
again. (About the best thing I can say for it in this regard is that
it's NOT the International Standard for Lisp; it's the International
Standard for ISLISP, one of many dialects in the Lisp family. The
Lisp community is being very careful to refer to Lisp as the language
family and not to allow any particular dialect to usurp the generic
name "Lisp". ISLISP is not an acronym; it's just a gensymed name
for yet another Lisp.)
It's more or less "culturally compatible" with ANSI CL, for whatever
that's worth; its datatypes are not radically different and it could
co-reside in the same address space without confusion. It came out
better than I expected, but is so small that it has very little value
unless heavily extended; and if extended, said extensions are not
going to be standard, so it is (IMO) crippled in its ability to pull
any community together. (Your mileage may vary.)
See http://osiris.dknet.dk/JTC1/SC22/WG16/ for more info, including a
pointer to a downloadable .dvi file. (I tried to make a .ps file just
now, but dvips 'helpfully' tries to send the result to the printer
automatically, which I don't want, so I had to Control-C it. Does
anyone know how to disable that stupid feature? My doc on dvips does
not say.)
If you're expecting it to supersede ANSI CL, I wouldn't hold your
breath. There seems little danger of that.
My role? I was/am US international representative from J13 (formerly
X3J13) to ISO's SC22/WG16 working group that created the ISLISP
standard; in that regard, I represented the US--particularly the CL
community--by voting on technical matters. (The US Scheme community
followed the matter early on but after a while lost interest and
decided the impact on them was small enough that they didn't want to
track it.) I was also the Project Editor for the standard itself;
that means I wrote the text, but as a neutral scribe, working from
technical decisions made by the committee--I had no design discretion
while operating in this role. I am not empowered, however, to speak
officially for the committee, so my remarks here are
anecdotal/documentary in nature, but do not represent official policy
views of anyone--just my personal opinions and memories.
> - are there any "conforming implementations"?
I'd be curious to hear the anwer, too, from anyone who knows of any.
Rainer Joswig
<pit...@world.std.com> wrote:
> > - are there any "conforming implementations"?
>
> I'd be curious to hear the anwer, too, from anyone who knows of any.
OpenLisp:
Kent M Pitman
> In article <sfwk94l...@world.std.com> you write:
> >pointer to a downloadable .dvi file. (I tried to make a .ps file just
> >now, but dvips 'helpfully' tries to send the result to the printer
> >automatically, which I don't want, so I had to Control-C it. Does
> >anyone know how to disable that stupid feature? My doc on dvips does
> >not say.)
>
Ah. Thanks. I just now created
ftp://ftp.harlequin.co.uk/pub/kmp/iso/v20/pd-islisp.ps
ftp://ftp.harlequin.co.uk/pub/kmp/iso/v20/pd-islisp.ps.gz
for anyone who didn't know what to do with the already-existing:
ftp://ftp.harlequin.co.uk/pub/kmp/iso/v20/pd-islisp.dvi
Actually, though I specified this as a URL, we've had trouble with
browser downloads timing out. I recommend you just use conventional
anonymous ftp (user "anonymous" password "your...@yourhost.whatever")
and get /pub/kmp/iso/v20/pd-islisp.ps.gz (or just .ps if you
don't have gnu's gunzip or the like).
Hannu Koivisto
| See http://osiris.dknet.dk/JTC1/SC22/WG16/ for more info, including a
| pointer to a downloadable .dvi file. (I tried to make a .ps file just
| now, but dvips 'helpfully' tries to send the result to the printer
| automatically, which I don't want, so I had to Control-C it. Does
| anyone know how to disable that stupid feature? My doc on dvips does
| not say.)
"dvips foo.dvi -o", perhaps? OTOH, if you have so strange
version that neither the manual page nor "dvips --help" mention
the -o option (it's mentioned on my dvips' manual page and help),
then that option may simply not be available.
Well, .dvi is better for me anyway, because people usually
convert their .dvis to some lousy resolution below 1200dpi ;)
Thanks for the pointer,
--
Hannu Koivisto | What you see is all you get.
NOYB | - Brian Kernighan
-------------------------------------------------------------
Kjetil Valstadsve
> When does it make sense to crosspost to both groups ?
When you're announcing a gang shootout?
--
- Musicians. And I don't mean good musicians, I mean jazz musicians
< Kjetil Valstadsve <k...@pvv.org>, <k...@computas.com> <
Howard R. Stearns
> ...
> > - how is it supposed to differ from ANSI CL?
>
> It's tiny. It's not an ANSI CL subset. It's not a Scheme subset.
> It's not a Eulisp subset. It is, alas, new design by committee yet
> again. (About the best thing I can say for it in this regard is that
> it's NOT the International Standard for Lisp; it's the International
> Standard for ISLISP, one of many dialects in the Lisp family. The
> Lisp community is being very careful to refer to Lisp as the language
> family and not to allow any particular dialect to usurp the generic
> name "Lisp". ISLISP is not an acronym; it's just a gensymed name
> for yet another Lisp.)
>
> It's more or less "culturally compatible" with ANSI CL, for whatever
> that's worth; its datatypes are not radically different and it could
> co-reside in the same address space without confusion. It came out
> better than I expected, but is so small that it has very little value
> unless heavily extended; and if extended, said extensions are not
> going to be standard, so it is (IMO) crippled in its ability to pull
> any community together. (Your mileage may vary.)
One of the charges made against Common Lisp is that although it is
complete enough to be genuinely useful, its size intimidates beginners.
Are there any opinions (of those who have actually looked at the
language spec) that ISLisp might be valuable to students and others who
are just beginning to learn Lisp?
For example, I could imagine people being encouraged to "begin learning
Lisp" by working in ISLisp. Then, when they are ready to begin
real-world applications, they could "painlessly" switch to Common Lisp.
It's been a while since I looked, but I was under the impression that
the principle way in which ISLisp was not a subset of CL was the
treatement of dynamic variables. (There are also some different, but
more-or-less compatible, differences in streams and I/O.) In particular
there are no big incompatibility such as nil/#f/() or lisp-1/lisp-2.
If all this is true, would it make sense for someone to whip up a public
ISLISP package for CL, which could be used by people writing tutorials,
etc.
Reini Urban
like AutoCAD or MS Office for example.
It has a nice and simple integretion with c or c++ functions, much
simplier than clisp (which is of course much better).
And it obviously has some WinAPI (MFC) integration but lacks the
documentation.
And it would terribly need to work as an ActiveX client (terrible word I
know) to be accepted in the windows world. The others windows lisps
don't have it neither (xlisp, clisp, acl, lww) so it cannot embrace the
office market. Windows scripting hosts are the latest hit and
a real lisp (even if it's only a islisp) would be much better than vb,
java, perl, python or lispz. (the only lisp i know so far with this
feature. but this is too simple.)
acl 5 is supposed to have it (according the webpage) but i didn't
download it so far and it's too large and too expensive anyway. lww 5
was also supposed to support MS OLE/COM but the version 4.1, which is in
beta, only has simple DDE support so far.
I already contacted the author about his plans for the future. he still
seems to work actively on it, trying to compile it on every single c
compiler which exists. :) (without any warnings)
i really like the fact that gimp (the new linux imaging package) has a
scheme as scripting language. why not photoshop, 3ds studio max or
future -hopefully better- office products? schedulers and such.
there's the money.
Kent M Pitman <pit...@world.std.com> wrote:
>It's tiny. It's not an ANSI CL subset. It's not a Scheme subset.
>It's not a Eulisp subset. It is, alas, new design by committee yet
>again. (About the best thing I can say for it in this regard is that
>it's NOT the International Standard for Lisp; it's the International
>Standard for ISLISP, one of many dialects in the Lisp family. The
>Lisp community is being very careful to refer to Lisp as the language
>family and not to allow any particular dialect to usurp the generic
>name "Lisp". ISLISP is not an acronym; it's just a gensymed name
>for yet another Lisp.)
>
>It's more or less "culturally compatible" with ANSI CL, for whatever
>that's worth; its datatypes are not radically different and it could
>co-reside in the same address space without confusion. It came out
>better than I expected, but is so small that it has very little value
>unless heavily extended; and if extended, said extensions are not
>going to be standard, so it is (IMO) crippled in its ability to pull
>any community together. (Your mileage may vary.)
---
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
Kent M Pitman
> One of the charges made against Common Lisp is that although it is
> complete enough to be genuinely useful, its size intimidates beginners.
That's so. But the reality of the modern world (by which I mean, the world
of the last 3-5 years) is that it is no longer a viable option to assume
that you have learned a language just because you know its core syntax.
Every language in sight is suddenly, almost overnight, sporting a huge library
base and if you begin by programming only in the "small kernel" the most
common programming error you will make is "reinventing the wheel".
One reason Common Lisp, even in 1980 when it began, was designed as it
was is because those of us writing "real programs" at the time were
absolutely tired of writing yet another version of the zillion things we
already knew that EVERYONE needed. Coding has improved immensely since
the presence of the standard functionality in Common Lisp, IMO. If anything,
Common Lisp is now way too small because out of paranoia we have held its
size constant for now a decade (feature freeze for ANSI CL was 1988) while
other languages have been growing by leaps and bounds.
If you want to teach or sell a subset, NOTHING in the standard keeps you
from doing that. We specified how to do subsetting and we specified the
wording to use to say you conform to a subset.
The X3J13 considered a teaching subset in detail and concluded finally
that there was no such uniquely determined concept. People were all
over the map with suggestions about what to remove for teaching,
depending on what they wanted to teach, what they didn't like, what
programming style they preferred, etc. EVERY teacher wants to teach a
different subset and it's not up to the standards-makers to say how
something is to be taught incrementally.
> Are there any opinions (of those who have actually looked at the
> language spec) that ISLisp might be valuable to students and others who
> are just beginning to learn Lisp?
There are those who think it would be valuable just like that. There are
those who think otherwise. They are surely both right. What makes it true
is not some fundamental aspect of the universe, but the choice of teacher.
One must choose tools appropriate to the skill and style of the teacher,
and to the needs and goals and abilities of the students. No single
solution fits all.
> For example, I could imagine people being encouraged to "begin learning
> Lisp" by working in ISLisp. Then, when they are ready to begin
> real-world applications, they could "painlessly" switch to Common Lisp.
Some say you can begin to learn programming in Scheme. Are they wrong?
You may have to be retaught some things later, or maybe not, depending
on the teacher. Does that matter?
ISLISP uses different words and syntax for many of the same concepts
as CL. Does that matter? How is that fundamentally different than
learning Scheme first? Personally, I think the answer must come from
the heart of the teacher and (to the extent s/he's qualified to opine),
the heart of the student.
> It's been a while since I looked, but I was under the impression that
> the principle way in which ISLisp was not a subset of CL was the
> treatement of dynamic variables. (There are also some different, but
> more-or-less compatible, differences in streams and I/O.
There are a lot of naming differences. The way you have to think
about arrays are different, although the supported set of
representational types is fundamentally compatible. ILOS is simpler
than CLOS, but so is a CLOS subset simpler than CLOS; the only
differences is that to move from ILOS to something else, you have
to learn more than "extensions", and to move from a CLOS subset to
something else, you don't.
) In particular
> there are no big incompatibility such as nil/#f/() or lisp-1/lisp-2.
This point is correct, and is what I refer to when I mention "cultural
compatibility". Certain changes are disastrous for co-resident
dialects, and things like the splitting of NIL or a shift to lisp1
were avoided.
> If all this is true, would it make sense for someone to whip up a public
> ISLISP package for CL, which could be used by people writing tutorials,
> etc.
Personally, I don't think so. It can certainly be done. I think it's
a bad way to go. If there were a source of ISLISP programmers coming
to CL and looking for a leg up on CL without relearning a lot of
stuff, I'd say go to it. But since there is not, I don't see teaching
people a lot of different names for things just so they'll have to
unlearn them later. You or anyone else would (IMO) be better off just
subsetting CL for your own purposes (and being content just to ignore
people who were not interested--there's no cost to the community of
having people disinterested in a subset--subsets only help us).
But a non-subset such as ISLISP can only divide the community, IMO,
by creating fights over the right way to do things.
In the Maclisp days (late 1970's), we used to have two string packages
and it created all kinds of wars over which was better. Such sparring
is useless. Just look at the wars between C implementations--ANSI C
vs non-ANSI C. It serves to divide the community and does little to
make programs better compared to the cost of having things not work
here or there. C would have been better off making the library part
of the language and saying you cannot vary it. Whether it's always
resident in your code is a separate question--I believe completely in
layering and am sad you don't have to say (REQUIRE 'PRETTY-PRINTER) or
(REQUIRE 'DEBUGGER) to get certain add-on features of CL. But that's
different than saying that people are permitted to vary the details of
the pretty printer; I think if you require it, the semantics should be
nailed down.
One of the most important contributions of Lisp to the computer
industry, IMO, is not its features 'per se' but the language as an
existence proof that 'defining a feature, even arbitrariliy' is more
important and powerful and enabling than haggling over the best
definition. Take 'program is data'. Any language can represent itself.
Even machine language. Lisp is often touted for "being able to"
represent itself. But that wasn't the contribution. The contribution
was "being willing to". It was ending hours of debate about how programs
would be represented and saying "they're just lists, ok?" They could as
well have been arrays, and some people think it would have been better.
But it didn't turn out to matter, because what mattered was that we
agreed, not that we had the best implementation. Because once you
agree, you go on to build things on top of what you agreed on. ANd
when you make small ssystems because you can't agree on the stuff to
layer atop, you hold back progress.
It's not that I'm saying programming shouldn't be simple. My model of
"good programming" is like the programming they do on Star Trek. They
often say a sophisticated thing or two, but they largely rely on racks
of libraries of pre-defined things to keep programs short. I care a
lot more about short programs than about small languages. Small languages
make long programs, and large languages make small programs. That's why
natural languages are large--so you can say things in finite space.
(You, not me. I always say everything in long form. :-) And that's
what I'm saying about ANSI CL--nothing about the fact that it has lots
of library stuff keeps you from focusing on the basics at the time you
need to. But the presence of useful stuff shouldn't keep you from
getting things done; you can always ignore it. It's harder to ignore
the absence of something when you don't want to be duplicating what
you know someone has long ago done.
Just one person's opinion. And hey, I'm still on vacation! Now back
to something comparatively easy like writing that scifi novel, in
future times where no one fights over language subsets any more...
Hartmann Schaffer
> ...
> now, but dvips 'helpfully' tries to send the result to the printer
> automatically, which I don't want, so I had to Control-C it. Does
> anyone know how to disable that stupid feature? My doc on dvips does
> not say.)
According to the dvips man page:
-f makes it act as a filter (stdin -> stdout)
-o file sends the ps output to "file"
> ...
--
Hartmann Schaffer
Guelph, Ontario, Canada
scha...@netcom.ca (hs)
Scott Fahlman
Kent M Pitman <pit...@world.std.com> writes:
> Scheme and Common Lisp, as communities, do not value the same things.
> Scheme and Common Lisp, as languages, do not provide the same things.
> Scheme and Common Lisp people do not think about or do things the same way.
> Scheme and Common Lisp do not attract the same people.
Hi Kent...
This is a slight overstatement, I think. For example, I seem to
recall that Guy Steele had something to do with the design of both
Scheme and Common Lisp, and I don't think he turned against Scheme
after working on CL. Yes, the Scheme and CL cultures have different
values, but some people can find both attractive.
I'm a Common Lisp guy and I'm not a big fan of the "too pure to be
useful" orientation that dominates the Scheme standardization groups.
I can't think of any large, complex application for which I would
choose Scheme over CL, unless maybe I wanted to make heavy use of
continuations and didn't need all the CL machinery that is absent in
Scheme. But I have recommended Scheme as a preferable langauge for
some classes of beginners because it is so much less cluttered than CL
and because of there are a couple of excellent textbooks that feature
Scheme.
-- Scott
===========================================================================
Scott E. Fahlman Internet: s...@cs.cmu.edu
Principal Research Scientist Phone: 412 268-2575
Department of Computer Science Fax: 412 268-5576
Carnegie Mellon University Latitude: 40:26:46 N
5000 Forbes Avenue Longitude: 79:56:55 W
Pittsburgh, PA 15213 Mood: :-)
===========================================================================
Kent M Pitman
> Kent M Pitman <pit...@world.std.com> writes:
>
> > Scheme and Common Lisp, as communities, do not value the same things.
> > Scheme and Common Lisp, as languages, do not provide the same things.
> > Scheme and Common Lisp people do not think about or do things the same way.
> > Scheme and Common Lisp do not attract the same people.
>
> Hi Kent...
Hi, Scott. Glad to see we managed to say something to get you to come
out of the woodwork. ;-)
> This is a slight overstatement, I think. For example, I seem to
> recall that Guy Steele had something to do with the design of both
> Scheme and Common Lisp, and I don't think he turned against Scheme
> after working on CL. Yes, the Scheme and CL cultures have different
> values, but some people can find both attractive.
Surely. And, as outlined in my Personal FAQ
http://world.std.com/~pitman/pfaq/cross-posting.html
I don't mean to say that one person can't read both lists. Only that
the discussion is often better if it happens separated because when
discussions are accompanied by a set of groundrules and values, they
tend to be more constructive. There is no one right answer to
the question which is "Computation". But there are, I think, right
answers in the context of a set of goals and needs. That doesn't mean
one of those sets of goals and needs is correct; just that it's best
to constraint things.
There is nothing about black and white line drawing, or oil painting,
or crayons, or bitmapped gifs, or HDTV, or photographs, or sculpting
that is uniquely better as an artform. But something that indiscriminately
involves them all rarely wins art awards. Each "values" a certain set
of principles at the expense of others, but at the benefit of yielding
a certain set of "internally consistent aesthetic principles".
To paint an oil painting is not to turn against sculpting. Nor did I mean
to turn against Scheme. But to assert the principles of sculpting on
a watercolor discussion list may miss the point, even if there are values
in common (such as "smooth flowing lines" or "harmony of color").
> I'm a Common Lisp guy and I'm not a big fan of the "too pure to be
> useful" orientation that dominates the Scheme standardization groups.
> I can't think of any large, complex application for which I would
> choose Scheme over CL, unless maybe I wanted to make heavy use of
> continuations and didn't need all the CL machinery that is absent in
> Scheme. But I have recommended Scheme as a preferable langauge for
> some classes of beginners because it is so much less cluttered than CL
> and because of there are a couple of excellent textbooks that feature
> Scheme.
Well, I'm more hesitant about recommending Scheme as a teaching
language but not for any reasons normally cited. My concern might be
analogous to a concern that a non-Christian might have in using the
Bible as a teaching text for ethics. There are some extraordinarily
good things taught in the Bible but there are some controverisal
points as well. And whether one sees it as a good teaching text may
not be a function purely of the goodness of the positives taught, but
also of the baggage of the negatives. And I emphasize that I do not
think the baggage of Scheme or its texts to be the language, but
rather other aspects of the texts themselves. There are things
therein that should inspire people but don't. And things therein that
people should ignore as incidental, but somehow raise to religious
signifance. And it is often as painful to unteach the incidentals as
to teach the grand truths, so from a standpoint of someone who's seen
Scheme programmers try to settle into business situations and use what
great things they learned from Scheme without being crippled by the
grand mythology they picked up by accident at the same time, I
consider it a wash. Others' mileage may, of course, vary.
My concerns are less a criticism of the language more of the teaching
curricula themselves, though they do reflect themselves in the
language because of its attempt to be minimal. CL's "ball of mud"
philosophy accomodates more variety. I have several pet peaves but the
most strong is that "tail recursion" was, I think, originally intended
to be an exercise in "expanding one's set of tools to include a new
way of thinking". An extra arrow in the programming quiver. But it
has not gone that way in practice. The assumption is that you will
learn the "iteration paradigm" elsewhere and that it need not be
explicitly lauded in Scheme classes. HOWEVER, because iteration
paradigms like (dotimes (i 10) (print i)) are ignored, students learn
(and deeply) not that "there is an iterative way of describing a loop
and also there is a tail recursive way and each provides interesting
ways to view the same computation" but rather "iteration is bad and
tail recursion is good". When I was taught Lisp, people learned DO
and were taught to see the equivalence relation between variables
with inits and steps and tail recursion with initial arguments and
arguments used in recursive calls; that is no longer emphasized, or is
lost by students coming out of these scheme classes who either come
out having not learned the material at all because "recursion is too
confusing and they can't relate it to anything or else come out
with a militant deathwish for iteration statements everywhere. So
much for scheme as a vehicle for enlightenment, IMO.
STILL, all that said, I will even concede for purposes of debate that
it is not an unreasonable claim for someone to make that the presence
and availability of Scheme both in the market and in the classroom is
an enormous benefit. I think there should be a place for Scheme to be
discussed and lauded and praised, or if criticized, criticized in the
context of what it is trying to be, not what outsiders think it is.
The same for Common Lisp. But to cc both lists is to force each group
to be all things to all people, and that strains things too much.
I hope that clarifies my position, at least to the degree that you
don't think this is about turning one's back on one or the other
community. It's more about making sure everyone has a forum in which
their speech is both welcome and understood. The larger and more
diverse the group, the less I think that can happen.
--Kent
p.s. Maybe you're just faked out by the "vs." in the subject line.
It gives a very "us vs them" quality to the discussion, but
I'm just responding under the thread that was already there.
Jeff Dalton
>
>> Scheme is by many people viewed as some dialect of Lisp.
>
>FWIW, not by me.
>
>differences between Lisp and Scheme that are just as major as between
>languages in the Algol family.
So? I used to be standard to make that point about different Lisps --
that, though often called "dialects", they differed as much as
languages in the Algol family. There are such differences *within*
Lisp, and Scheme is far from the only example.
The real problem is "dialect", which is why "family of languages"
was used e.g. in X3J13 submissions to ISO WG-16.
>Scheme and Common Lisp, as communities, do not value the same things.
The same could be said about the Interlisp and Maclisp communities.
>Scheme and Common Lisp, as languages, do not provide the same things.
The same could be said about other Lisps.
>Scheme and Common Lisp people do not think about or do things the same way.
And Common Lisp people vs Cambridge Lisp people vs Le Lisp people vs ...
>Scheme and Common Lisp do not attract the same people.
Like above.
Yes, you are failing miserably to show Scheme is not a dialect of Lisp.
-- jd
Jeff Dalton
Kent M Pitman <pit...@world.std.com> wrote:
>Lisp community is being very careful to refer to Lisp as the language
>family
*Was*. Until some people returned older ways of talking when saying
such things as how Scheme wasn't a "dialect of Lisp". :-)
-- jd
Kent M Pitman
> >Lisp community is being very careful to refer to Lisp as the language
> >family
>
> *Was*. Until some people returned older ways of talking when saying
> such things as how Scheme wasn't a "dialect of Lisp". :-)
In this remark only, I wasn't talking about casual speech. Sorry for
failing to elaborate.
I was alluding to the fact that ISO actually published a draft
document which referred to the standard as a "LISP" standard and we
managed to get them to change it as an editorial error (and not MY
editorial error, I hasten to add--something they helpfully "fixed"
after I submitted the document for review) because so many countries
objected. It was at an awkward time when we would have had to make a
technical objection and screw up the timeline to get it fixed;
fortunately, they fixed it administratively and asked us to continue
voting as if the document had not had this error. It was procedurally
a real mess.
X3J13, too, was under periodic pressure to simply call its standard a
standard for LISP, and the committee refused, to avoid stepping on the
toes of others.
Individuals, of course, are not so organized about whether they're
stepping on each others' toes. It's part of the stuff of life.
Kent M Pitman
> In article <sfwr9yu...@world.std.com>,
> Kent M Pitman <pit...@world.std.com> wrote:
> >Klaus Schilling <Klaus.S...@home.ivm.de> writes:
> >
> >> Scheme is by many people viewed as some dialect of Lisp.
> >
> >FWIW, not by me.
> >
> >Don't let the parens fool you. There are a number of really key
> >differences between Lisp and Scheme that are just as major as between
> >languages in the Algol family.
>
> So?
Did I object to the part about "many people" viewing Scheme as a
dialect of Lisp? (I didn't. I just said I don't. And I enumerated
my reasons. As with all opinions, some people will care and some will
not. The opposing point of view, which you apparently take, is so
commonplace I hardly worry that it needs to be belabored. I was
merely documenting a minority opinion.)
> The real problem is "dialect", which is why "family of languages"
> was used e.g. in X3J13 submissions to ISO WG-16.
I have no problem with this alternate characterization, and I thank
you for reminding me about this quibble. It's true that we're not
dealing with an exact science when talking about the classification
of languages--to me, whether you say "dialects within a family" or
"languages within a langauge family" is of no consequence; my main
point is that (to me) the gap between "things within" and "things
without" is different.
You have to read my "Lambda The Ultimate Political Party" paper
if you want to see my views on the reasons outlined more fully.
I will try to briefly answer some of your other points in spite of
that, though. But I'm not looking to establish a truth; I'm merely
looking to log an opinion. You're welcome to your alternate
opinion. PLease just don't tread on my welcome to express mine.
> >Scheme and Common Lisp, as communities, do not value the same things.
>
> The same could be said about the Interlisp and Maclisp communities.
Somehwat. I define (in the above paper) the metric of whether something
is the same language to refer to how many people the language serves
as a political constituent base. Since Maclisp was directly supplanted
by Common Lisp, and since many major applications in Maclisp chose to
accept Common Lisp as a successor, my view is that Common Lisp is strongly
in the Maclisp camp.
Some number of people were alienated by the choice of Common Lisp to
support the higher end, larger applications. This created a new
political community which was interested in small lisps. Previosuly,
there was no such distinction, and it's subjective which group the
name goes with in a split. I choose in my mind to associate it with
the "large projects" that were being done. You may wish otherwise.
But again, the point is not the names but the fact of the political
split. A political split creates a new language, a dialect (IMO) does
not.
To me, a dialect (like Maclisp for big application builders vs LispM
vs CL) is just a local choice for reasons of custom, not a deeply
rooted philosophical choice for reasons of ideal. To me, because the
LispM sought to attract and succeeded in attracting the CL market, the
LispM was a dialect. To me, because Scheme did not care about running
the LispM applications nor running the Maclisp applications and was
more interested in creating its own group of users (its own political
constituent base) it was not a different dialect.
> >Scheme and Common Lisp, as languages, do not provide the same things.
>
> The same could be said about other Lisps.
I've argued otherwise. I personally consider the metric of the degree
to which two languages provide the same things (which is not a binary
division, after all) to be whether programmers with applications in
the language choose to port their applications to that language. There was
not a heavy motion of applications from Maclisp to Scheme. There was
from Maclisp to CL. It's fine if you find this criterion uninteresting.
I am simply noting that I do not.
> >Scheme and Common Lisp people do not think about or do things the same way.
>
> And Common Lisp people vs Cambridge Lisp people vs Le Lisp people vs ...
Asked and answered.
> >Scheme and Common Lisp do not attract the same people.
>
> Like above.
Asked and answered.
> Yes, you are failing miserably to show Scheme is not a dialect of Lisp.
Since this was not my goal, I'm not very concerned about that.
People are often too stuck in their ways for me to make it my life's
work to try to change them. If I thought words, even well-reasoned
and well-argued ones (which I don't always assert my newsgroup posts
to be), could REALLY change people, I'd spend my effort converting C
people to Lisp, not converting Jeff Dalton to a belief in this obscure
notion. ;-)
But I think the only way you can really convert people--whether to God
or Lisp or Republicanism or Vegetarianism--is to do good works and
hope that at some point people respect you enough for what you've done
that they will, of their own accord, take a few minutes to investigate
how you think and how you got to where you did in life. That's why
people who people respect tend to win debates whether they say
rational things or not, and why people who aren't respected are
ignored in spite of the points they advance.
And anyway, life is short. Sooner than we all wish, none of us will
be around to debate this any more. The obvious opinions are already
plentifully on the record. I just sometimes like to get the less
obvious opinions onto the record, too. Not because I expect people to
be swayed by me, but just so the historians won't be utterly bored
when they come to read what people of our time thought about.
Mike McDonald
Kent M Pitman <pit...@world.std.com> writes:
> je...@interactive.co.uk (Jeff Dalton) writes:
>
>> In article <sfwr9yu...@world.std.com>,
>> Kent M Pitman <pit...@world.std.com> wrote:
>> >Klaus Schilling <Klaus.S...@home.ivm.de> writes:
>> >
>> >> Scheme is by many people viewed as some dialect of Lisp.
>> >
>> >FWIW, not by me.
>> >
>> >Don't let the parens fool you. There are a number of really key
>> >differences between Lisp and Scheme that are just as major as between
>> >languages in the Algol family.
>>
>> So?
>
> Did I object to the part about "many people" viewing Scheme as a
> dialect of Lisp? (I didn't. I just said I don't. And I enumerated
> my reasons. As with all opinions, some people will care and some will
> not. The opposing point of view, which you apparently take, is so
> commonplace I hardly worry that it needs to be belabored. I was
> merely documenting a minority opinion.)
I wonder if it is that much of a minority opinion, at least from the
Maclisp/ZetaLisp/CommonLisp viewpoint. It seems to me that Lispers aren't as
interested in "religous" issues as the Schemers. Hence, we don't really care
whether they call Scheme a "Lisp" or not. Amongst ourselves, we know what we
mean when we say Lisp. (Maclisp/ZetaLisp/CommonLisp!)
I've never considered Scheme to be a Lisp. Sure, it has some similarities
to Lisp. But then C does to Pascal and we don't normally put them in the same
language "family". By and large, the two languages have disjoint philosophies
and user groups. As much as I try, I can never get used to using Scheme. It's
just too different to feel comfortable. (I feel more comfortable writing C
than I do Scheme!) And I know Schemers who say the same thing about Lisp.
But since I'm a Common Lisper, if it makes the Schemers happy to call Scheme
a "dialect of Lisp", go for it. Whatever makes you happy.
Mike McDonald
mik...@mikemac.com
Rainer Joswig
mik...@mikemac.com wrote:
> But since I'm a Common Lisper, if it makes the Schemers happy to call Scheme
> a "dialect of Lisp", go for it. Whatever makes you happy.
I think Scheme is a dialect of Lisp. Am I a "Schemer"? ;-)
Mike McDonald
I don't know. Do you find Lisp or Scheme easier to use? Or are you one of
those rare individuals who fills at home using both?
Mike McDonald
mik...@mikemac.com
Martin Rodgers
> I think Scheme is a dialect of Lisp. Am I a "Schemer"? ;-)
Perhaps. I think we can make these distinctions between CL and Scheme
because we're "insiders". Please note my pedantic qualification; I'm not
using the name "Lisp" as that is ambiguous in this context.
How would a C programmer see it? To anyone who doesn't use or know any
Lisp at all, both CL and Scheme would look the same. This is why I can't
tell you what kind of Lisp code I first saw. I only knew it was Lisp.
Not everyone appreciates the differences between dialects, languages, or
even compilers! We do. That means that we can make pedantic distinctions
that would boggle most other people, no matter how good our reasons.
As someone who has to keep explaining to people (different people, thank
goodness) the difference between compilers and interpreters, languages
and implementations, and sometimes even more "obvious" distinctions, I
think I can see the other side to this. If you have to fight over the
question, then you may already have your answer. It's not necessarily a
_binary_ issue! If only it were that simple...
Ask not on UseNet, for they shall say "Yes", "No", and "Ask in another
newsgroup." ;)
--
Remove insect from address to email me | You can never browse enough
"Ahh, aren't they cute" -- Anne Diamond describing drowning dolphins
Rainer Joswig
mik...@mikemac.com wrote:
> I don't know. Do you find Lisp or Scheme easier to use?
Nice try. ;-) Scheme is a dialect of Lisp. Common Lisp is
a dialect of Lisp.
Scheme is easy. Typically my code
is using a bit more FP-idioms. A bit of discipline
(naming, ...) and there you go.
> Or are you one of
> those rare individuals who fills at home using both?
I know some other people who are fluent in CL *and* Scheme.
We have written Unix and CGI scripts in Scheme (SIOD and scsh)
before, but now we are doing a lot of our stuff in CL.
We have a lot of applications where we can/could
use both interchangeably. For my purposes Scheme looks
like a CL subset (plus call-with-current-continuation).
Various Scheme implementations add their own capabilities
(SIOD adds its small size and its libraries for
Unix/web applications, scsh adds its integration into Unix, ...).
We have replaced in one project SIOD + Web client with
CL + CL-HTTP, etc.
Martin Rodgers
> Scheme is a dialect of Lisp. Common Lisp is
> a dialect of Lisp.
Agreed. If it walks like a duck, quacks like a duck, then it _is_ a duck.
Mike McDonald
m...@wildcard.butterfly.demon.co.uk (Martin Rodgers) writes:
> In article <joswig-1108...@194.163.195.67>, jos...@lavielle.com
> says...
>
>
> Perhaps. I think we can make these distinctions between CL and Scheme
> because we're "insiders". Please note my pedantic qualification; I'm not
> using the name "Lisp" as that is ambiguous in this context.
In this newsgroup, I don't think the term "Lisp" is ambiguous at all. By and
large, in means the Maclisp/ZetaLisp/CommonLisp line. How often do we discuss
Scheme related issues in this newsgroup?
> How would a C programmer see it?
C programmers would see that Scheme and Lisp were syntacticly similar and
very different from what they're used to and group the two together as THEM.
> As someone who has to keep explaining to people (different people, thank
> goodness) the difference between compilers and interpreters
That one I'd love to hear sometime!
Mike McDonald
mik...@mikemac.com
Mike McDonald
jos...@lavielle.com (Rainer Joswig) writes:
> For my purposes Scheme looks
> like a CL subset (plus call-with-current-continuation).
Ah, a Lisper in Scheme clothing. :-)
Mike McDonald
mik...@mikemac.com
Mike McDonald
jos...@lavielle.com (Rainer Joswig) writes:
> In article <VX2A1.16150$MV.11...@news.teleport.com>,
> my copy of Macintosh Common Lisp. Will it reduce my
> credibility as a Lisper (CLer?)? ;-)
Oh, yuck! A Schemer wearing Lisp clothing! Run for the hills! Save the women
and children! :-)
Mike McDonald
mik...@mikemac.com
Rainer Joswig
> In article <joswig-1108...@194.163.195.67>,
> jos...@lavielle.com (Rainer Joswig) writes:
>
> > For my purposes Scheme looks
> > like a CL subset (plus call-with-current-continuation).
>
> Ah, a Lisper in Scheme clothing. :-)
>
> Mike McDonald
> mik...@mikemac.com
Maybe I shouldn't show you this part of the config code for
my copy of Macintosh Common Lisp. Will it reduce my
credibility as a Lisper (CLer?)? ;-)
#+cl-http-menu
(cl-http-menu:add-item-to-tool-menu
"Load PseudoschemeŠ"
#'(lambda ()
(load "ccl:lisp-software;Pseudo Scheme;loadit.lisp")
(cl-user::load-pseudoscheme))
"Enables the use of Scheme within MCL."
:activate nil)
#+cl-http-menu
(cl-http-menu:add-item-to-tool-menu
"Run PseudoschemeŠ"
#'(lambda ()
(eval-enqueue (read-from-string "(ps:scheme)")))
"Starts Scheme within MCL."
:activate t)
Which gives you:
Welcome to Macintosh Common Lisp Version 4.2!
?
This is Pseudoscheme 2.12.
? (define (foo bar) (+ bar 3))
foo defined.
? (foo 3)
6
?
Oops!
forcer
<jos...@lavielle.com> wrote:
[...]
>Maybe I shouldn't show you this part of the config code for
>my copy of Macintosh Common Lisp. Will it reduce my
>credibility as a Lisper (CLer?)? ;-)
>
>
>Which gives you:
>
>Welcome to Macintosh Common Lisp Version 4.2!
>?
>This is Pseudoscheme 2.12.
>? (define (foo bar) (+ bar 3))
>foo defined.
>? (foo 3)
>6
>?
You mean this is like #define BEGIN { in other communities? :)
seriously, this thread is pretty pointless.
Scheme is Scheme, CL is CL, other Lisps are other Lisps, and Lisp in the
meaning of "LISt Processing" fits for both ("lot's of surplous paranteses
fits as well for both if you think it fits for one)
Anyways, in Scheme i'm missing NIL and T, and in CL i'm missing those easy
function define's (thanks for your snipped :) ...
Oh, and since i consider this thread pointless and don't want to lengthen it
any further... (followup-to 'poster)
-forcer
--
/* A beer delayed is a beer denied. */
/* email: for...@mindless.com -><- www: http://webserver.de/forcer/ */
/* IRC: forcer@#StarWars (IRCnet) -><- PGP/GPG: available on my website */
Martin Rodgers
mik...@teleport.com says...
> > Perhaps. I think we can make these distinctions between CL and Scheme
> > because we're "insiders". Please note my pedantic qualification; I'm not
> > using the name "Lisp" as that is ambiguous in this context.
>
> In this newsgroup, I don't think the term "Lisp" is ambiguous at all. By and
> large, in means the Maclisp/ZetaLisp/CommonLisp line. How often do we discuss
> Scheme related issues in this newsgroup?
I didn't say "this newsgroup". I said "this context". Hence my "Please
note my pedantic qualification." You may define "Lisp" as Maclisp /
ZetaLisp / CommonLisp, but while we're discussing the question of
definitions, such definitions require qualifications.
To avoid confusion like this.
> > How would a C programmer see it?
>
> C programmers would see that Scheme and Lisp were syntacticly similar and
> very different from what they're used to and group the two together as THEM.
Exactly. Some programmers might not even consider many details of the
syntax. An expression like (list (car x) (car y) (cdr x)) uses the same
syntax in CL and Scheme. The semantics may be a little different (the car
and cdr functions behave differently), but to a programmer unfamiliar
with any form of Lisp, this isn't an issue. As insiders, we know and care
about such details, as they can critically affect the behavoir of our
code.
> > As someone who has to keep explaining to people (different people, thank
> > goodness) the difference between compilers and interpreters
>
> That one I'd love to hear sometime!
Yeah, the explanation is that there is _no_ difference! I can't believe
that two weeks ago I had to _yet again_ tell someone that a Basic
interpreter need not be slow. I don't particularly care what people think
of Basic, but I'd like to kill the myth that interpreters are "slow".
In this case, the context was comms, and the question was whether a
Basic interpreter was too "slow" to use for scripting! Good grief.
I prefer to make a distinction between good and bad implementations. This
also applies to Lisp, whatever form it takes. The distinction between
good and bad programmers is even more critical, IMHO. I'd prefer to work
with a good programmer using a language I dislike than with a bad
programmer (mis)using a language I love.
This is why I'm not concerned about the differences between CL and
Scheme. I use them both, and for different things. I see no conflict.
David Thornley
>
>> Kent M Pitman <pit...@world.std.com> writes:
>>
>> > Scheme and Common Lisp, as communities, do not value the same things.
>> > Scheme and Common Lisp, as languages, do not provide the same things.
>> > Scheme and Common Lisp people do not think about or do things the same way.
>> > Scheme and Common Lisp do not attract the same people.
>>
starts talking about C/C++ on comp.lang.c. C and C++ are closer than
Common Lisp and Scheme, since there is a common subset that's a complete
language: you can write significant programs that will compile and work
identically under both C and C++.
The reason for keeping the two separate is the sort of advice you'd give
and the sort of approach you'd recommend. If I saw a program with
a statement
sutff = (int *)malloc(100 * sizeof(int));
I'd suggest changing it to either
sutff = malloc(100 * sizeof *sutff);
or
sutff = new int[100];
depending on whether this is C or C++ (both the above are illegal
in one of the two languages).
Similarly, you can do object-oriented programming in either, but
it is much easier in C++ (for OOP, CLOS:C++::C++:C), so I'd
suggest object-oriented programming for more things in C++ than in C.
C++ has a string class, which is much easier to use than C's strings.
Except that CL and Scheme have different syntaxes, I'd say much the
same is true there. If I see deep recursion being a problem, should
I recommend tail recursion or a loop? How much should I use set!/setf?
My current big project is written in CL. It uses objects, loops,
arrays, and destructive operations heavily. (OK, it's not a
traditional "lispy" program, and would require a large amount of
work to port to Lisp 1.5. I'm still exceedingly glad I didn't have to
do it in C++ or Ada or Java or any of the other wunderlanguages
being hyped.) Since I'm using fairly generic CL, it should port nicely
from MCL to any other CL (yeah, even the graphics, once I get CLTk
a bit more developed).
If I had done it in Scheme, I would have done it far differently
(of course, if I'd done it in C, no way would it work by now).
This is why I tend to think of Common Lisp and Scheme as being
separate languages in the Lisp tradition.
ObConfession: I, too, have been guilty of using Lisp to refer to
Common Lisp and related languages. Knowing me, I'll probably
continue to do it, without much regret.
--
David H. Thornley | These opinions are mine. I
da...@thornley.net | do give them freely to those
http://www.thornley.net/~thornley/david/ | who run too slowly. O-
Kent M Pitman
> > > As someone who has to keep explaining to people (different people, thank
> > > goodness) the difference between compilers and interpreters
> >
> > That one I'd love to hear sometime!
>
> Yeah, the explanation is that there is _no_ difference!
I disagree. Some interpreters are defined to do minimal syntactic
pre-processing first, but in a way, that really defeats the original
purpose of having an interpreter. In the text below, I assume that
restriction is not a fundamental property of all interpreters. (I'd
have to look, but I don't even think it's a required property of CL.
I think you only have to do "minimal compilation" if you use
COMPILE or COMPILE-FILE in an interpreted implementation. Ah well,
read on and you'll see why this matters... (And if you wonder what
"minimal compilation" is about, see the HyperSpec's compiler chapter.)
An interpreter is lazy in its semantic attachment, producing a
compile-time vs run-time speed trade-off. It is typically cheap to
define but expensive to execute because it only semantically processes
the executed paths; compiled code, by contrast, is typically expensive
to compile and cheap to execute because it has to compile all paths
whether they will be executed or not, but once it goes to execute them
it doesn't have to think about them.
This makes a material difference in execution speed, which you can
MOSTLY gloss if you don't define your semantics to involve execution
speed. However, it also makes a difference that cannot be ignored:
consider that in a language like Lisp that is BOTH interactive and
introspective, the fact of having traversed only some paths can matter.
In particular, in the face of redefinition, it can lead to (and in
older Lisps, where "macro memoization" was common, used to ROUTINELY
lead to) inconsistencies in macro definitions if macros were redefined
between executions on unrelated data. Consider this example which
will trigger the effect in most modern common lisps:
(defmacro foo (x &whole form)
(rplaca form 'first))
(defun bar (x flag) (if flag (foo x) (foo x)))
(bar '(a b) t)
=> A
(defmacro foo (x &whole form)
(rplaca form 'second))
(bar '(a b) t)
=> B
(mapcar #'(lambda (x) (bar '(a b) x)) '(t nil nil t nil))
=> (A B B A B)
They also, incidentally, typically take different amounts of time to
code and take up different amounts of space in an image. Typically a
compiler contains declarative or abstract knowledge and must reason
about hypothetical situations that may not come up or may not be
relevant in some cases; it has no access to runtime data. An
interpreter can typically be more modular, reason more efficiently,
etc. because it never deals in hypotheticals. Of course, the
reasoning that it's doing is reasoning that is conceptually "compile
time reasoning" and is done many times instead of one if the
information is not memoized; and if it is memoized, it costs the
runtime user rather than the compile-time user space to do the
memoization. So again, there are many shifts in time producing
"trade-offs" (not necessarily "degradations") in both directions. As
always with "trade-offs", you win sometimes and you lose sometimes,
and no result is absolutely right.
And, finally, if I remember Steele's "cheapy" Scheme compiler
correctly (which I think was one of the compilers he wrote on the way
to his "rabbit" compiler), its resulting "compiled code" ran slower
than interpreted code, even leaving out the step of how long it took
to compile. That's actually a useful result to know about because it
underscores the perhaps non-obvious fact that mere "compilation" does
not a priori ensure faster code, all other issues aside. It depends
on what you compile into!
> I'd like to kill the myth that interpreters are "slow".
Note well, I'm not saying interpreters are "slow". I'm saying that
compilers do extra work at compile time, and interpreters do extra
work at runtime, and that this can produce a measurable skew. Whether
it's material is not the same as whether it's measurable. And indeed,
sometimes the whole point can be that the interpreter will be faster
because the compiler is slow and to execute one line of code may be
quicker in the interpreter. So don't think I'm disagreeing with this;
a claim about relative speed (especially two unrelated kinds of
relative speed, added together) is not the same as a claim about
absolute speed.
> I prefer to make a distinction between good and bad implementations.
Note also that what I'm saying is also orthogonal to the goodness/badness
issue.
My point here, just to be clear, is that compilers and interpreters do
have different properties, however subtlely they are manifested. And
that it is worth acknowledging that under the general category of
"nothing in the world is every really free--everything is a trade-off,
no trade-off wins 100% of the time".
- - - - -
In the related phenomena department, since my mind works like a big
analogy web and I can't think of one of these things without thinking
of its friends, CL seems to define MAPCAN as the same as
(apply #'nconc (mapcar ...))
but that's not the way Maclisp did it. Maclisp did the nconc's
"coroutined" with the mapping so that when you were done, it was
already joined. You'd maybe think that was just an optimization
(just as you'd think compiling was "just an optimization over
interpreting") but consider that you can construct (well, that
I once managed to construct and had to debug, but can't remember
now) where if you nconc after, you only got a circular result but
if you nconc as you go, you got a circular list earlier--while you
are still traversing the list--and ended up never terminating the loop.
So it wasn't simply an optimization to nconc as you went along--it was
a program-visible change in semantics. And in both the MAPCAN case and
the interpreter/compiler case we find that it's not just "what you say
you'll do" but "when you say you'll do it" and doing things in a
different order sometimes matters (like as if that should surprise
anyone--but somehow it often does in both of these cases!)
Martin Rodgers
> I disagree. Some interpreters are defined to do minimal syntactic
> pre-processing first, but in a way, that really defeats the original
> purpose of having an interpreter.
This is the full technical explanation. I usually find that the people
who claim that some language is "slow" don't understand the full-on
compiler theory that you or I might prefer.
Your points are good, but I prefer to simply refer people to PJ Brown's
book, "Writing Interactive Compilers and Interpreters". Lisp programmers
are a rather different breed, and the examples around here should be
representative. Many of us here will have written Lisp compilers and
interpreters, which means that you're "preaching to the converted".
In other words, you've just demonstrated my point about insiders and
outsiders. I never have to explain this stuff to insiders.
> Note well, I'm not saying interpreters are "slow". I'm saying that
> compilers do extra work at compile time, and interpreters do extra
> work at runtime, and that this can produce a measurable skew.
Noted. PJ Brown makes this point well in the above book. Yet another
reason why I refer so many people to it!
> Note also that what I'm saying is also orthogonal to the goodness/badness
> issue.
Noted. I think we're in agreement; we just find ourselves addressing
different groups of people. Your points here are addressed to CS literate
programmers, while I often find myself dealing with non-programmers and
programmers who appear to be totally non-CS literate.
I could just say, "No, language X is _not_ slow. Trust me." In the comms
scripting example from two weeks ago, I could've just said, "Look at the
amount of comms software that uses interpreted scripting!" In fact,
somebody else gave a very specific example. Another just said, "Nope."
As you said, everything is a trade-off, and no trade-off wins 100% of the
time. This is why pure interpreters and pure compilers are uncommon. They
can sometimes be useful, but in general we use something that somewhere
in between the two extremes.
Since 1985, I've seen Lisp as a tool that let's me choose where the
compromise is, not just between compiled and interpreted code, but
between general and specialised domains. I used to be dogmatic in my
thinking, and insisted on only using CL to build support for my
specialised domains.
A few years ago I discovered Scheme, I read SICP, and I began to
reconsider my attitudes. I remembered _why_ I used Lisp, and what it was
that attracted me to Lisp in the first place. I liked dynamic languages
years before I found Lisp. This is what brought me to Lisp!
I think of Lisp as the tool with which I can realise the languages I want
to use. It's merely a starting point. Isn't this what SICP is about? If
these ideas could only be applied in Scheme, then the book probably
wouldn't be of as much interest to CL programmers as it is.
Everything should be of _some_ interest to a Lisp programmer, whether
that Lisp is CL, Scheme, Standard Lisp (I briefly used that during my
fanatical CL period, but hated it because of my puritan CL feelings
[sigh]), because if an idea is good, then we can also use it in Lisp.
"That which does not kill Lisp makes Lisp stronger." ;)
Mike McDonald
Kent M Pitman <pit...@world.std.com> writes:
> m...@wildcard.butterfly.demon.co.uk (Martin Rodgers) writes:
>
>> > > As someone who has to keep explaining to people (different people, thank
>> > > goodness) the difference between compilers and interpreters
>> >
>> > That one I'd love to hear sometime!
>>
>> Yeah, the explanation is that there is _no_ difference!
>
> I disagree.
> An interpreter is lazy in its semantic attachment, producing a
> compile-time vs run-time speed trade-off. It is typically cheap to
> define but expensive to execute because it only semantically processes
> the executed paths; compiled code, by contrast, is typically expensive
> to compile and cheap to execute because it has to compile all paths
> whether they will be executed or not, but once it goes to execute them
> it doesn't have to think about them.
But someone does. After all, assembler IS an interpreted language.
I personally think you hit upon one of distinctions in my mind. That is the
compiler will "examine" all possible execution paths where as the interpreter
"examines" only the relevant paths to this execution. But then you throw in
JIT compilers and incremently compiling interpreters and the distinction gets
muddy.
>> I'd like to kill the myth that interpreters are "slow".
>
> Note well, I'm not saying interpreters are "slow". I'm saying that
> compilers do extra work at compile time, and interpreters do extra
> work at runtime, and that this can produce a measurable skew.
To me, compilers split the cost of doing computation into two parts, some
amount of "preprocessing" time (P) and execution time (E). Interpreters lump
it all into one time (T). Whether P+E < T is pretty much irrelevant to the
compiler guys since they're assuming (rightly or wrongly) that what they're
optimizing is that P+NE be much less than NT, where N is some number of runs
greater than 1. Interpreter guys tend to believe that N is usually some
fraction less than 1. (ie most of the code doesn't get executed.)
Mike McDonald
mik...@mikemac.com
Jeff Dalton
>> >Scheme and Common Lisp, as languages, do not provide the same things.
>>
>> The same could be said about other Lisps.
>
>I've argued otherwise. I personally consider the metric of the degree
>to which two languages provide the same things (which is not a binary
>division, after all) to be whether programmers with applications in
>the language choose to port their applications to that language. There was
>not a heavy motion of applications from Maclisp to Scheme. There was
>from Maclisp to CL. It's fine if you find this criterion uninteresting.
>I am simply noting that I do not.
It's a fine criterion. But the fact is that different Lisps often do
not provide the same things and that there is often not a heavy motion
of applications from one Lisp to the other. Maclisp and CL are pretty
close within the Lisp familty. But some other pairs of Lisps are not
so close. The differences that obtain among languages in the Lisp
family are great enough so that Scheme can reasonably be included,
despite the greater distance between Maclisp and Scheme than between
Maclisp and CL.
>> >Scheme and Common Lisp people do not think about or do things the same way.
>>
>> And Common Lisp people vs Cambridge Lisp people vs Le Lisp people vs ...
>
>Asked and answered.
Really? You don't appear to have addressed Cambridge Lisp or Le Lisp
or "..." at all.
>> >Scheme and Common Lisp do not attract the same people.
>>
>> Like above.
>
>Asked and answered.
Ok, then, again: You don't appear to have addressed Cambridge Lisp or Le Lisp
or "..." at all.
I've spent a lot of time talking to Lisp people who were not attracted
to Common Lisp (the "do not attract the same people" point) and who
thought about things in a noticeably un-Common-Lisp-like, and for that
matter un-Maclisp-like, way (that's the "do not thing about or do
things the same way" point). It's simply true that this is what
things are like in the Lisp family and that the situation wrt Scheme
is not all that different.
>> Yes, you are failing miserably to show Scheme is not a dialect of Lisp.
>
>Since this was not my goal, I'm not very concerned about that.
Ok, you present a view and provide reasons and what seem to be
arguments for it, but you're not trying to "show" it. But close
enough, I would say.
>People are often too stuck in their ways for me to make it my life's
>work to try to change them.
How did we get to this "life's work" stuff? This is just a few
articles in a net discussion, no?
>But I think the only way you can really convert people--whether to God
>or Lisp or Republicanism or Vegetarianism--is to do good works and
>hope that at some point people respect you enough for what you've done
>that they will, of their own accord, take a few minutes to investigate
>how you think and how you got to where you did in life. That's why
>people who people respect tend to win debates whether they say
>rational things or not, and why people who aren't respected are
>ignored in spite of the points they advance.
So this is about winning debates now?
In any case, I hope people are willing to look at what's said (rather
than only at who says it) and to think about and to look into things
for themselves.
My view is that (1) "___ is a dialect of Lisp" and "___ is a language
in the Lisp family" have been two ways to say pretty much the same
thing, the move to talk of a family of languages happening in part
for (good) political reasons in connection with standardization;
and (2) when we divide up "language space" into families, Scheme
ends up in the Lisp family.
For a long time -- since at least the 70s -- people have (rightly)
pointed out that different Lisps, though often called "dialects",
differ as much as different "langauges" in the Algol family.
Such differences do not stop something from being a "dialect of
Lisp" or "member of the Lisp family of languages" -- instead
they're part of what the Lisp family is like.
[BTW, I'm sorry if my tone in some messages seems too hostile.
I have an annoying news connection that makes it difficult to spend
much time on messages, and haste gives me a more polemical style.
In any case, I will contine to defend the truth rather than mere
opinion. :-) ]
-- jd
Jeff Dalton
Mike McDonald <mik...@mikemac.com> wrote:
[re KMP's "minority opinion" that Scheme is not a dialect of Lisp]
> I wonder if it is that much of a minority opinion, at least from the
>Maclisp/ZetaLisp/CommonLisp viewpoint. It seems to me that Lispers aren't as
>interested in "religous" issues as the Schemers. Hence, we don't really care
>whether they call Scheme a "Lisp" or not. Amongst ourselves, we know what we
>mean when we say Lisp. (Maclisp/ZetaLisp/CommonLisp!)
Which will annoy some people who prefer different Lisps within the
Lisp family. I agree, BTW, that in the Maclisp/ZetaLisp/CommonLisp
part of the world, things are usually taken fairly pragmatically.
This may be a difference from Scheme, but it's also a difference
from some other parts of the Lisp world.
> I've never considered Scheme to be a Lisp. Sure, it has some similarities
>to Lisp. But then C does to Pascal and we don't normally put them in the same
>language "family".
But can we not put Algol 60, Algol 68, Algol-W, Formula Algol, and
for that matter Simula and probably others whose names I can't
remember right now in a "family"? And wouldn't they be in a
family even if their names were changed. Surely it's not just
a matter of names! But I rather suspect that names have an
influence. Anyway ...
There have been Lisps, called "Lisp", and intended to be Lisp, that
were in fact quite like Scheme. But I rather suspect there wouldn't
have been a very widespread opinion that they weren't Lisp (unless, of
ocurse, there was widespread adoption of a "religious" view that only
languages very close to, say, Maclisp/ZetaLisp/CommonLisp were
"really" Lisp).
>By and large, the two languages have disjoint philosophies
>and user groups.
In my experience, there is substantial overlap in both user group
and philosophy between Scheme and various Lisps.
-- jd
Jeff Dalton
Mike McDonald <mik...@mikemac.com> wrote:
>In article <MPG.103ab8d61...@news.demon.co.uk>,
> m...@wildcard.butterfly.demon.co.uk (Martin Rodgers) writes:
>>
>>> I think Scheme is a dialect of Lisp. Am I a "Schemer"? ;-)
>>
>> because we're "insiders". Please note my pedantic qualification; I'm not
>> using the name "Lisp" as that is ambiguous in this context.
>
> In this newsgroup, I don't think the term "Lisp" is ambiguous at all. By and
>large, in means the Maclisp/ZetaLisp/CommonLisp line. How often do we discuss
>Scheme related issues in this newsgroup?
To me, and to a fair number of others, "Lisp" in this newsgroup means
Lisp, and Lisp includes quite a few languages other than the Maclisp/
ZetaLisp/CommonLisp line. And if you don't think Lisp includes for
instance Lisp 1.5, Lisp 2, Interlisp, PSL, EuLisp, ISLISP and all the
many differing "Lisps" people used to create before standardization,
then I think you're just wrong. (I could try to mention by name lots
of little-known Lisps such as Eclisp and DTSS Lisp, but I hope that's
not necessary.)
-- jd
Jeff Dalton
Martin Rodgers <m...@wildcard.butterfly.demon.co.uk> wrote:
>This is why I'm not concerned about the differences between CL and
>Scheme. I use them both, and for different things. I see no conflict.
I'm glad a couple of people have mentioned that they use both Scheme
and Common Lisp. I also use both, and I've translated programs
from Scheme to Common Lisp (or the other way). When the only Lisp
I had for my machine at home was PC Scheme, I did all of my "Lisp"
programming in Scheme. I thought in pretty much the same way and
wrote pretty much the same sort of code and it never occurred to
me that there might be a widespread view that Scheme was somehow
not Lisp.
Moreover, when I've devised a Lisp variant and implemented it
(which I've done a fair number of times) it was often fairly
close to Scheme (once I'd heard of Scheme, of course).
Fortunately, no on came along and said "you haven't really
implemented Lisp at all, turkey". :-)
-- jeff
Kent M Pitman
> Fortunately, no on came along and said "you haven't really
> implemented Lisp at all, turkey". :-)
Fortunately, no one has called anyone a turkey in this entire
discussion either.
Martin Rodgers
je...@interactive.co.uk says...
> I'm glad a couple of people have mentioned that they use both Scheme
> and Common Lisp. I also use both, and I've translated programs
> from Scheme to Common Lisp (or the other way). When the only Lisp
> I had for my machine at home was PC Scheme, I did all of my "Lisp"
> programming in Scheme. I thought in pretty much the same way and
> wrote pretty much the same sort of code and it never occurred to
> me that there might be a widespread view that Scheme was somehow
> not Lisp.
I've sometimes written similar code in both CL and Scheme. I've also
translated code from one to the other, and been curious about the
differences in style I've used. Performing this exercise with C and eithr
CL or Scheme, I see much bigger differences.
When I'm using a pure FP language like Haskell, I have to try to think in
Haskell rather than Lisp. It's sometimes easier to write C code while
thinking in Lisp, but only because I'm actually seeing Lisp code and
translating it into C - and back again, when I edit it.
I pick up something from every language I use, and incorporate it into my
programming style. Sometimes this requires some "utility" code, like my
stack string vocab for Forth (modeled on the string functions in a very
old MS Basic). If I were still writing Forth code, I'm sure I'd have a
"Lisp" vocabulary by now. It would be fun to see how much Lisp code could
be re-written using such a vocab. Forth style influences my Lisp style,
so I like to write very short expressions. It's easier to do this in
Haskell, where a series of one line definitions is very natural!
> Fortunately, no on came along and said "you haven't really
> implemented Lisp at all, turkey". :-)
Nah, I'm the turkey around here. ;)
Kent M Pitman
> (defmacro foo (x &whole form)
> (rplaca form 'first))
>
> (defun bar (x flag) (if flag (foo x) (foo x)))
>
> (bar '(a b) t)
> => A
>
> (defmacro foo (x &whole form)
> (rplaca form 'second))
>
> (bar '(a b) t)
> => B
>
> (mapcar #'(lambda (x) (bar '(a b) x)) '(t nil nil t nil))
> => (A B B A B)
The arg order is wrong in the two defmacro forms.
&whole has to come first. I fixed this in the listener
I typed this in to, but I didn't apparently fix it back in
the mail. e.g.,
(defmacro foo (&whole form x)
(rplaca form 'first))
and the same for the other.
Sorry for the confusion.
It was some version of LispWorks on Unix where I got the behavior above;
not sure which version. LispWorks for Windows pre-processes forms so
doesn't see this behavior. Neither behavior is a bug; CL permits a
discrepancy here in interpreted code. Only compiled code is required
to process a form's semantics fully at a known time. See "minimal
compilation" in CLHS.
Mike McDonald
je...@interactive.co.uk (Jeff Dalton) writes:
> In any case, I hope people are willing to look at what's said (rather
> than only at who says it) and to think about and to look into things
> for themselves.
That's sound advise.
> For a long time -- since at least the 70s -- people have (rightly)
> pointed out that different Lisps, though often called "dialects",
> differ as much as different "langauges" in the Algol family.
> Such differences do not stop something from being a "dialect of
> Lisp" or "member of the Lisp family of languages" -- instead
> they're part of what the Lisp family is like.
So then, what is the criteria by which some programming language is measured
by to determine whether it is or is not a "lisp"? Is Cambridge Prefix Notion
all that's required? That it have cons cells? That it was designed by a "lisp"
programmer? That the users hate C/C++?
> [In any case, I will contine to defend the truth rather than mere
> opinion. :-) ]
>
> -- jd
Truth? There's no such thing! But that's a different philosophical
discussion. :-)
Mike McDonald
mik...@mikemac.com
John Atwood
>Exactly. Some programmers might not even consider many details of the
>syntax. An expression like (list (car x) (car y) (cdr x)) uses the same
>syntax in CL and Scheme. The semantics may be a little different (the car
>and cdr functions behave differently), but to a programmer unfamiliar
>with any form of Lisp, this isn't an issue. As insiders, we know and care
>about such details, as they can critically affect the behavoir of our
>code.
What are the differing semantics of
(list (car x) (car y) (cdr x))
in Scheme and CL?
John
Lyman S. Taylor
John Atwood <atw...@ice.CS.ORST.EDU> wrote:
>Martin Rodgers <m...@wildcard.butterfly.demon.co.uk> wrote:
...
>
>What are the differing semantics of
> (list (car x) (car y) (cdr x))
>in Scheme and CL?
If X and/or Y are () in Scheme the above will invoke an error. In
Common Lisp, the result of the whole expression if X and Y are ()
is ( NIL NIL NIL ).
CAR and CDR have the same name in both. What they do is different, but
there is plenty of overlapped to lull you into thinking they are
exactly the same ( with a non empty list as an argument).
--
Lyman S. Taylor "Because no matter where you go,
(ly...@cc.gatech.edu) there you are."
Buckaroo Banzai
Martin Rodgers
> What are the differing semantics of
> (list (car x) (car y) (cdr x))
> in Scheme and CL?
Consider the possible values of x and y. If x is '(), how will car
behave? The answers are below.
R5RS:
(car '()) ==> error
ANSI Common Lisp:
If x is a cons, car returns the car of that cons. If x is nil, car
returns nil.
Frank Adrian
> Truth? There's no such thing! But that's a different philosophical
>discussion. :-)
Oh yes there is, and its value is #t. Or is it t? Or just not nil? Oh
well, whatever...
--
Frank A. Adrian
First DataBank
frank_...@firstdatabank.com (W)
fra...@europa.com (H)
This message does not necessarily reflect those of my employer,
its parent company, or any of the co-subsidiaries of the parent
company.
Mike McDonald
"Frank Adrian" <frank_...@firstdatabank.com> writes:
> Mike McDonald wrote in message ...
>> Truth? There's no such thing! But that's a different philosophical
>>discussion. :-)
>
> Oh yes there is, and its value is #t. Or is it t? Or just not nil? Oh
> well, whatever...
Don't you mean not #f?
Mike McDonald
mik...@mikemac.com
Jeffrey Mark Siskind
> > Truth? There's no such thing! But that's a different philosophical
> >discussion. :-)
>
> Oh yes there is, and its value is #t. Or is it t? Or just not nil? Oh
> well, whatever...
> Frank A. Adrian
This is great. I haven't laughed so hard in weeks. I'd like to ask your
permission to quote the above when the need arises.
Will Hartung
>In article <6r1qd5$772$1...@client2.news.psi.net>,
> "Frank Adrian" <frank_...@firstdatabank.com> writes:
>> Mike McDonald wrote in message ...
>>> Truth? There's no such thing! But that's a different philosophical
>>>discussion. :-)
>>
>> Oh yes there is, and its value is #t. Or is it t? Or just not nil? Oh
>> well, whatever...
> Don't you mean not #f?
Well, there is certainly a lot of truth in #f.
--
Will Hartung - Rancho Santa Margarita. It's a dry heat. vfr...@netcom.com
1990 VFR750 - VFR=Very Red "Ho, HaHa, Dodge, Parry, Spin, HA! THRUST!"
1993 Explorer - Cage? Hell, it's a prison. -D. Duck
Jeff Dalton
>> Fortunately, no on came along and said "you haven't really
>> implemented Lisp at all, turkey". :-)
>Fortunately, no one has called anyone a turkey in this entire
>discussion either.
Where's your ":-)"?
-- jd
Jeff Dalton
Mike McDonald <mik...@mikemac.com> wrote:
>In article <902971906.12647.0...@news.demon.co.uk>,
> je...@interactive.co.uk (Jeff Dalton) writes:
>> For a long time -- since at least the 70s -- people have (rightly)
>> pointed out that different Lisps, though often called "dialects",
>> differ as much as different "langauges" in the Algol family.
>> Such differences do not stop something from being a "dialect of
>> Lisp" or "member of the Lisp family of languages" -- instead
>> they're part of what the Lisp family is like.
>
>So then, what is the criteria by which some programming language is measured
>by to determine whether it is or is not a "lisp"? Is Cambridge Prefix Notion
>all that's required? That it have cons cells? That it was designed by a "lisp"
>programmer? That the users hate C/C++?
None of those things are necessary; nor are any of them "all that's
required".
In philosophy, there's a view, usually traced back to Wittgenstein,
with "game" as the canonical example, that the things that fall under
a concept need have only a "family resemblance". The idea is that
there needn't be anything they all have in common, and there needn't
even be a definition in terms of necessary and sufficient conditions.
This is sometimes "cashed in" by saying the concept is specified
by a cluster of properties, where something is a member of the family
if it has "enough" of the propeties, and how much is enough is left
somewhat vague.
>> [In any case, I will contine to defend the truth rather than mere
>> opinion. :-) ]
> Truth? There's no such thing!
Yes, there is, but it's not a thing. :-)
Anyway ... for a good discussion of truth, see _Theories of Truth, A
Critical Introduction_, by Richard L. Kirkham, MIT Press, 1995.
-- jd
Paolo Amoroso
wrote:
> Sam Steingold <s...@goems.com> writes:
>
> > BTW, could someone say a couple of words about islisp?
> > like:
[...]
> > - are there any "conforming implementations"?
>
> I'd be curious to hear the anwer, too, from anyone who knows of any.
If nobody is aware of any implementations, it seems that ISLISP is not used
much. So why was the standard defined in the first place?
This question suggests another, more general one: is there enough demand
from the market or from the research community to justify the creation of
new Lisp _standards_ (i.e. not just special-purpose language extensions or
customized implementations)?
Paolo
--
Paolo Amoroso <amo...@mclink.it>
Kent M Pitman
> This question suggests another, more general one: is there enough demand
> from the market or from the research community to justify the creation of
> new Lisp _standards_ (i.e. not just special-purpose language extensions or
> customized implementations)?
You begin from the assumption that the only reason someone would want
to make something was that it was a good idea. What if it was just
trying to take the place of a worse idea.
I suspect the nuclear arms race came not out of a desire of all
countries to be sitting on a lot of bombs, but out of a (real or
imagined) recognition that this was better than what would happen
if one was not sitting on a lot of bombs and someone else who was
got "aggressive".
If you were the US and saw other dialets of Lisp being evolved
overseas, or you were a European country or Japan and saw the US
starting to dominate the Lisp "family/dialect/call-it-what-you-will"
marketplace, can you imagine participating in the standard to avoid
something bad happening? And then once participating, if your only
choice was "adopt something that exists that you don't want",
"convince someone else to adopt something they don't want", or "make
up a compromise dialect that no one wants but that isn't as bad for
any given party as adopting somebody else's choice unmodified", how do
you thionk you would recommend things proceed?
The complexity in the world is caused not by stupidity of the
participants but by their cleverness in trying to cope with a heavily
overconstrained world that doesn't offer them the choices they want.
Barry Margolin
Paolo Amoroso <amo...@mclink.it> wrote:
>If nobody is aware of any implementations, it seems that ISLISP is not used
>much. So why was the standard defined in the first place?
Because there was a faction that didn't want Common Lisp to become an ISO
standard, and the only way they could prevent it was by defining an
alternate standard.
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Jeff Dalton
>
> In article <35d96d3...@news.mclink.it>,
> Paolo Amoroso <amo...@mclink.it> wrote:
> >If nobody is aware of any implementations, it seems that ISLISP is not used
> >much. So why was the standard defined in the first place?
>
> Because there was a faction that didn't want Common Lisp to become an ISO
> standard, and the only way they could prevent it was by defining an
> alternate standard.
How does an ISLISP standard *prevent* Common Lisp from becoming
and ISO standard? A major reason for calling it "ISLISP", after
all, was to avoid having the ISLISP standard be a standard for all
of (the) Lisp (family of languages).
-- jd
Jeff Dalton
> amo...@mclink.it (Paolo Amoroso) writes:
>
> > This question suggests another, more general one: is there enough demand
> > from the market or from the research community to justify the creation of
> > new Lisp _standards_ (i.e. not just special-purpose language extensions or
> > customized implementations)?
>
> You begin from the assumption that the only reason someone would want
> to make something was that it was a good idea. What if it was just
> trying to take the place of a worse idea. [...]
FWIW, I think KMP has got this exactly right (including in the
text I cut out to save space).
However, it's also worth noting that many *wanted* ISLISP to be more
than "a compromise dialect that no one wants". A fairly large amount
of work was put into this, but it's rather difficult to design a good
(and somewhat large) language, and it becomes harder when very little
work is done by e-mail, so that almost everything has to be worked out
at meetings without much preliminary discussion. The various
political factors also made progress difficult.
In the end, the only way to produce a language definition, rather
than just say "we failed", was to go for something relatively small
and not too offensive.
I think the ISLISP definition is worth reading. It has some good
features as a document, and the language is of at least historical
interest.
Meetings of WG-16 (the ISO technical committee for ISLISP
analogous to X3J13 for Common Lisp) were also an opportunity for
Lisp folk from different countries to discuss Lisp, which is
no bad thing.
-- jd
Barry Margolin
Jeff Dalton <je...@gairsay.aiai.ed.ac.uk> wrote:
>How does an ISLISP standard *prevent* Common Lisp from becoming
>and ISO standard? A major reason for calling it "ISLISP", after
>all, was to avoid having the ISLISP standard be a standard for all
>of (the) Lisp (family of languages).
While it doesn't strictly prevent it, it makes it less likely. The people
who decide what standards are needed might not feel the necessity for an
ISO Common Lisp standard, as ISLISP would be perceived to fill that niche.
Also, even if an ISO Common Lisp standard does come out, it gives people
who don't want to be forced to use it an alternative. Many governments
require use of ISO standards when applicable. Someone who wants to use
Lisp would then be able to choose between ISLISP and Common Lisp.
Kent M Pitman
> Barry Margolin <bar...@bbnplanet.com> writes:
> > Paolo Amoroso <amo...@mclink.it> wrote:
> > >If nobody is aware of any implementations, it seems that ISLISP
> > >is not used much. So why was the standard defined in the first
> > >place?
> > Because there was a faction that didn't want Common Lisp to become
> > an ISO standard, and the only way they could prevent it was by
> > defining an alternate standard.
>
> and ISO standard? A major reason for calling it "ISLISP", after
> all, was to avoid having the ISLISP standard be a standard for all
> of (the) Lisp (family of languages).
In my PERSONAL opinion...
Because it's the process that matters, not the document. The game is
in the participation and the mechanics of notification and voting and
so on.
And because ISO isn't substring-blind, and would give any other
petitions for work to the same group as a task. SC22/WG16 -is- a
"Lisp" working group as it was created. It didn't create a Lisp
standard by its own choice, not because it didn't have the ISO charter
to do it. That's what I meant when I said itw as an internal decision
of the Lisp community.
If you called the language something else--say, just as a complete
hypothetical, "Dylan"--they would probably make a new working group
for ISO Dylan unless someone insisted there was good reason to join
the two. (It would depend on how the work item creating it were
phrased by the proposer, but my point is that it would raise fewer
eyebrows if it didn't have "LISP" in its name). But then, the market
probably wouldn't be confused by the presence of ISO Dylan and ISO
ISLISP next to each other, as it probably would be ISO ISLISP and ISO
Common Lisp, again for the substring reason.
Georg Bauer
<bar...@bbnplanet.com> wrote:
>Many governments
>require use of ISO standards when applicable.
Yeah. Cool. And what happens now is, those governments have to go for
ISLISP, a language without an implementation. Very productive. Doesn't
sound like that gives a real boost for Lisp ...
bye, Georg
Kent M Pitman
> In article <j9jD1.40$DY4.7...@burlma1-snr1.gtei.net>, Barry Margolin
> <bar...@bbnplanet.com> wrote:
>
> >Many governments
> >require use of ISO standards when applicable.
>
> Yeah. Cool. And what happens now is, those governments have to go for
> ISLISP, a language without an implementation. Very productive. Doesn't
> sound like that gives a real boost for Lisp ...
(The following is just me personally speaking. As representative
of Harlequin to X3J13 and of the US to WG16, I have to be careful
not to speak for those organizations where they have not asked me to.
This information is offered just for anecdotal value, and isn't
intended to express any formal position of any organization or country.)
In the US, I'm told ISO standards are preferred over ANSI in various
government situations unless a good reason is offered. I think the
absence of a serviceable implementation would count; I've never heard
a Harlequin sales person say they lost a sale to ISLISP.
But certain countries (Japan and France, for example), argued that
ISLISP would be critical to them. It's not my role, nor any other
country's to second-guess their claim about what their country needs
any more than it is any other country's role to second-guess the US's
claim of what it needs. The US accepted their claim at face value,
and so the only question was properly framed as "Should we help them
achieve their stated goal or not?"
One of the thing that frustrates me more than any other in the
standards business is the difficulty of getting people to cooperate on
things they personally do not need. Often the easiest things are the
hardest. For example, if someone proposes a function like
(force-output stream)
because they use buffered I/O and someone else doesn't use
buffered I/O, the one who doesn't need it will see this as an inelegance
and insist it not be there. I find this irritating, but it's
very common. It would cost an implementation nothing to do
(defun force-output (stream) )
in the case where it's not needed but they don't do it for reasons
that amount to the lack of willingness to see that the request
is not unreasonable to someone else, and for lack of understanding
that failure to cooperate with others on matters where you can
cooperate leads to later disinterest on the part of those same
others to cooperate with you on something you need. FORCE-OUTPUT was
not an issue in ISLISP, but it's a metaphor for the kinds of issues
one faces when one party needs a thing and one party doesn't.
It's easier to get someone to agree on something everyone wants
because then they're motivated to negotiate from the outset.
As US representative, I was permitted by X3J13 to help. I suppose we
could have just allowed or encouraged the project to fail (and perhaps
it might have). Some even privately suggested that they expected us
to do so, and were surprised that we didn't just sabotage things. But
we didn't want to sabotage things, and even if we had, a failure might
have reflected badly on Lisp generally--bad press has a habit of
running out of control. So we went ahead. And I think a lot of good
came out of having people get past their initially-wary positions.
Everyone started out skeptical of everyone else, but by the end people
were more unified. Given the emotional wounds that were created by
the creation of Common Lisp during the days when intercontinental
communication was not as good, I think it was worth the exercise just
to repair some of the trust between a number of countries that care
about Lisp.
"A real boost for Lisp"? I can't show you proof. It may be delayed
or hard to measure. I think the biggest boon for Lisp may be the
absence of a failed standardization project for someone to point to.
I know that would have personally hurt some people who were big Lisp
supporters in their home countries, and I'm glad not to see them
having suffered that. And I suspect even in the countries where ISLISP
wasn't a big deal, the ripples of "failure" would have taken their toll.
So for a project that began out of fear of all concerned to have ended
successfully and with people being friendly, I think things ended
well.
I'm personally relieved and proud to say that when someone came to me,
to my company, and to my country and asked for help on something I/we
didn't especially need that I/we didn't just shrug and say "I don't
see a problem" or "That's your problem--why should I care?" Maybe
some day when I/we need someone else's understanding in a similar such
endeavor, we'll have some good will to trade on. Maybe people will
even learn that it's generally not so bad to try to care about other
people's needs and believe other people's concerns.
When I was younger and just starting out I used to think of things
in terms of allies and enemies and turf-grabbing. Now I think of it
in terms of "people like me" and "people who would be just like me
if they had my set of constraints" and "people I would be just like
if I had their constraints". It's been a real learning experience
for me in terms of human understanding and compassion.
(End of personal commentary)
Rainer Joswig
<pit...@world.std.com> wrote:
> But certain countries (Japan and France, for example), argued that
> ISLISP would be critical to them.
And? What happened? Was it critical to them? Just asking.
Kent M Pitman
> In article <sfwogtd...@world.std.com>, Kent M Pitman
> <pit...@world.std.com> wrote:
>
> > But certain countries (Japan and France, for example), argued that
> > ISLISP would be critical to them.
>
> And? What happened? Was it critical to them? Just asking.
I'm maybe not the one to really answer this. But that's never stopped
me before. Maybe one of them will still answer this and maybe they
won't, but I want to break normal protocol and, with all due respect
to you and your surely-innocent intentions, criticize the question
because the people of whom it is asked might not be listening or might
not be able to respond.
To see the problem in this question, I'll appeal to an analogy: Some
people claim the space program is "critical". Asking someone after we
went to the moon if it in fact turned out to be critical, though,
misses the point and introduces actual risk to people who support the
space program: (a) If someone answers "yes", it invites someone to say
"oh, come on, you're exaggerating!". Criticality can be subjective
and subjective issues invite debate, especially in a forum like this
that feels so "academic" to many participating. (b) If no one
answers, it seems like the answer must be "no" even though perhaps the
people who could answer are either not paying attention or are
forbidden from speaking publicly on the matter. (c) If someone
answers "no", often they are publicly embarrassing themselves or
someone they know who made the original claim because their dire
prediction was way off-base.
My feeling is that It has not appeared to impede anyone's sales force
from selling other Lisps. And even just its presence provides another
option to those vendors who might want it in the future, even if not
right away.
So I recommend you not push any harder for an answer, and just
consider this question "handled". I have no authority to require that
of you--it's a free speech forum. I just personally think it's best.
It may not be clear from the fact that I sometimes seem to ramble at
length on almost any topic, but I cringe whenever I have to answer an
ISO question of any kind. It is very, very, very hard to write such
an answer. This is the third mostly complete rewrite of this message
that I've written (each of about this length), trying to find the
right tone and to avoid saying things that would get me in trouble.
Being a representative for a country is very, very complicated. There
are just so many ways you can insult, confuse, embarrass, or
misrepresent your own people or those of some other country. Anything
you say can come back to haunt you. It's why I'm always having to
disclaim myself here. And then I have to worry if people understand
the depth of importance of the disclaimer. If I let down my guard for
even a minute, and this has really happened, I find some casual remark
I made is being requoted as "The US said xxx." instead of "Kent said
xxx." and suddenly there is an international incident to deal with.
It may not require scud missiles to resolve, but it does sometimes
cause a lot of resources to be wasted on all sides figuring out who
got confused and why, and then trying to undo the damage.
And rules about speaking publicly vary country to country. I could
elaborate a lot on this, and did in previous drafts of this message
that I didn't feel comfortable sending. I don't want to embarrass any
particular country or individual by doing so, and it's very hard to
know all the potential social conventions that one might step on.
It's just very very, very complicated for someone who hasn't been
through this to understand the degree to which personal, corporate,
and national "face" plays into this. I try to give you a general
sense of things, but in spite of the fact that I speak at length, I
cannot speak nearly as candidly as I'd like to any degree of
specificity in order to avoid singling out anyone. It is just more
energy and care than I'm willing to put into a newsgroup post, given
that the risks are high of botching something up. I like the
international harmony we created and don't want to undo that.
Anyway, sorry for running on at such length. I don't mean you to
feel bad for having asked the question. I'm just hoping to avert a
whole series of probing questions that I would never want to answer
if I were the people of whom this is apparently being asked.
Jeff Dalton
>> Barry Margolin <bar...@bbnplanet.com> writes:
>> > Paolo Amoroso <amo...@mclink.it> wrote:
>> > >If nobody is aware of any implementations, it seems that ISLISP
>> > >is not used much. So why was the standard defined in the first
>> > >place?
>> > Because there was a faction that didn't want Common Lisp to become
>> > an ISO standard, and the only way they could prevent it was by
>> > defining an alternate standard.
>>
>> How does an ISLISP standard *prevent* Common Lisp from becoming
>> and ISO standard? A major reason for calling it "ISLISP", after
>> all, was to avoid having the ISLISP standard be a standard for all
>> of (the) Lisp (family of languages).
>
>In my PERSONAL opinion...
>
>Because it's the process that matters, not the document. The game is
>in the participation and the mechanics of notification and voting and
>so on.
>
>And because ISO isn't substring-blind, and would give any other
>petitions for work to the same group as a task. SC22/WG16 -is- a
>"Lisp" working group as it was created. It didn't create a Lisp
>standard by its own choice, not because it didn't have the ISO charter
>to do it. That's what I meant when I said itw as an internal decision
>of the Lisp community.
But what was this faction that was trying to prevent CL from
becoming an ISO std "by defining an alternate standard"?
The alt std defined was ISLISP, which wouldn't prevent a CL std.
And WG-16 explicitly intended to define a standard that was
*not* for all of Lisp. The whole point of that is to let
other standards be possible.
-- jd
Jeff Dalton
>>and ISO standard? A major reason for calling it "ISLISP", after
>>all, was to avoid having the ISLISP standard be a standard for all
>>of (the) Lisp (family of languages).
>
>who decide what standards are needed might not feel the necessity for an
>ISO Common Lisp standard, as ISLISP would be perceived to fill that niche.
So far as I know, an ISO CL standard is possible and there's a "fast
track" method that might be used to create one. I don't think ISLISP
will cause any problems for a Scheme standard, and the problem of
the common substring in "ISLISP" and "Common Lisp" is surely one
that can be overcome.
But anyway what I was questioning was the idea that the reason for
ISLISP was to prevent an ISO CL std. There were, to be sure, people
who thought there should be only one ISO std in the Lisp area and
who didn't want CL to be that standard. But once work in ISLISP
started, it was explicitly not to make one std that covered all
of Lisp.
>Also, even if an ISO Common Lisp standard does come out, it gives people
>who don't want to be forced to use it an alternative.
Providing an alternative to CL and preventing an ISO CL std are not
the same.
-- jd
Jeff Dalton
Georg Bauer <g...@hugo.westfalen.de> wrote:
>In article <j9jD1.40$DY4.7...@burlma1-snr1.gtei.net>, Barry Margolin
><bar...@bbnplanet.com> wrote:
>
>>require use of ISO standards when applicable.
>
>Yeah. Cool. And what happens now is, those governments have to go for
>ISLISP, a language without an implementation. Very productive. Doesn't
>sound like that gives a real boost for Lisp ...
Has anyone been forced to use ISLISP?
I have not heard of anything like that actually happening.
-- jd
Kent M Pitman
> >And because ISO isn't substring-blind, and would give any other
> >petitions for work to the same group as a task. SC22/WG16 -is- a
> >"Lisp" working group as it was created. It didn't create a Lisp
> >standard by its own choice, not because it didn't have the ISO charter
> >to do it. That's what I meant when I said itw as an internal decision
> >of the Lisp community.
>
> But what was this faction that was trying to prevent CL from
> becoming an ISO std "by defining an alternate standard"?
> The alt std defined was ISLISP, which wouldn't prevent a CL std.
> And WG-16 explicitly intended to define a standard that was
> *not* for all of Lisp. The whole point of that is to let
> other standards be possible.
Well, I don't think it was that specific. As far as I can remember,
whether said dialects/languages were standard or not, and whether even
if standard they were national or international standards is not
something we discussed.
People and circumstances change and opinions with them. It's a bit
like the US Supreme Court (or perhaps any court). On one day,
something seems to be an impossibility because of how the people
present view the world, but later (perhaps with a change of world or
people viewing it), there seems to be no obstacle... AND vice versa.
There is no procedural way to prohibit a future action in ISO. If
there were, and instead of technical reports and standards, ISO
committees could create treaties, I suspect many committees would be
spared a lot of work. :-) But I suppose even treaties would find a way
to be broken, so maybe that's why they don't bother. In general, all
ISO gives you is ways to name past islands of consensus and ways to
create likelihoods you'll be in the loop if a future action, good or
bad, is attempted in your interest area.
(As usual in this discussion, this is all just my quite subjective
opinion and not an official statement of policy for my company or
country.)
Jeff Dalton
> je...@interactive.co.uk (Jeff Dalton) writes:
> > >And because ISO isn't substring-blind, and would give any other
> > >petitions for work to the same group as a task. SC22/WG16 -is- a
> > >"Lisp" working group as it was created. It didn't create a Lisp
> > >standard by its own choice, not because it didn't have the ISO charter
> > >to do it. That's what I meant when I said itw as an internal decision
> > >of the Lisp community.
> > But what was this faction that was trying to prevent CL from
> > becoming an ISO std "by defining an alternate standard"?
> > The alt std defined was ISLISP, which wouldn't prevent a CL std.
> > And WG-16 explicitly intended to define a standard that was
> > *not* for all of Lisp. The whole point of that is to let
> > other standards be possible.
> Well, I don't think it was that specific. As far as I can remember,
> whether said dialects/languages were standard or not, and whether even
> if standard they were national or international standards is not
> something we discussed.
> [...]
I guess what I wondering at this point is whether you agree with the
following, or not, as an answer to "So why was the [ISO] standard
defined in the first place?:
Because there was a faction that didn't want Common Lisp to become
an ISO standard, and the only way they could prevent it was by
defining an alternate standard.
For my part, I do not agree that the standard was defined in the first
place for that reason.
-- jd
Kent M Pitman
> I guess what I wondering at this point is whether you agree with the
> following, or not, as an answer to "So why was the [ISO] standard
> defined in the first place?:
>
> Because there was a faction that didn't want Common Lisp to become
> an ISO standard, and the only way they could prevent it was by
> defining an alternate standard.
>
> For my part, I do not agree that the standard was defined in the first
> place for that reason.
Well, I think there were Common Lisp factions (not just in the US)
that didn't want Eulisp to become an ISO standard either. I would
never phrase it in a one-sided way like you have. I'd just say that
various countries didn't want other nations' standards they didn't
internally endorse rising to the ISO level indiscriminately.
I would also never say there is a single reason. I think the reason
you cited was a contributing reason, but political questions are never
so simple. There are surely other reasons. That I haven't cited them
doesn't mean they don't exist. That you have another reason doesn't
mean I'm dismissing your reason.
The REAL reason, if there is one single simple reason the ISO process
happened, is that a question was formally posed whether we should make
a standard and when the voting members were polled, they voted yes.
Anything else is conjecture.
Rather than try to put words in my mouth and then disagree with them,
why don't you just say what you think and leave it to me to disagree
if I want to. Or, if there's an important reason I need to speak
first, say what that reason is. I've already volunteered enormously
more info on this than I am comfrotable offering to an international
audience of unknown compositio. As I said before, it's very very very
difficult for me to respond to these questions at all. It takes me a
lot more time and energy editing my reply than I would like to spend,
but I am also not comfortable seeing statements semi-attributed to me
(such as above) and so I feel forced to comment where I don't always
want to.
Barry Margolin
>happened, is that a question was formally posed whether we should make
>a standard and when the voting members were polled, they voted yes.
>Anything else is conjecture.
That's not a reason, it's a process. It's like using laws of physics and
biology to explain why someone was shot during a holdup. Clearly Jeff
wants to know why the question was posed, and why they voted yes.
>Rather than try to put words in my mouth and then disagree with them,
>why don't you just say what you think and leave it to me to disagree
>if I want to.
The words he quoted came out of *my* mouth (well, keyboard). I guess he
wanted to know if your assessment agreed with mine.
I admit that I oversimplified quite a bit, but I think the gist is still
correct. There was interest in an international standard for Lisp. If
Common Lisp became an ANSI standard, it would be very likely be adopted as
an ISO standard as well (it's relatively easy to "fast track" a national
standard through ISO). There were some Europeans who didn't want to be
forced to use Common Lisp (many countries have a very strong bias in favor
of using ISO languages). Starting a work item to define another Lisp
standard diverted efforts away from working on Common Lisp as an ISO
standard.
And you can simply look at the empirical evidence: Common Lisp *has* been
adopted as an ANSI standard, yet I don't think anyone has started the
project to get it prompoted to the ISO level. There's nothing stopping it,
but there's no longer a vacuum trying to be filled.
Andi Kleen
Could someone shortly explain the major differences between Common Lisp
and the current ISLisp draft?
-Andi
Erik Naggum
| Could someone shortly explain the major differences between Common Lisp
| and the current ISLisp draft?
for what it's worth, ISO/IEC 13816:1997 "Information technology --
Programming languages, their environments and system software interfaces
-- Programming language ISLISP", has been passed. it's 126 pages long.
the major difference? Common Lisp is an "a posteriori" standard, while
ISLisp is an "a priori" standard, i.e., for Common Lisp, experiences from
the real world preceded the creation of the standard, while in the ISLisp
case, the standard precedes experiences from the real world. ISO has
been a breeding ground for a priori standards lately, especially in the
"information technology" area. such standards usually fail to become
adopted, since nothing exists from which users migrate into complying
systems, and no implementation that has had years of experiences to iron
out the early design flaws and implementation problems to help implement
or migrate an implementation into compliance.
I fail to see any positive purposes of ISLisp, although I can see the
negative purposes of it becoming a standard very clearly. such is the
case of many features in standards and even in many standards. those who
like sausages, laws, and standards are well advised not to learn how they
are made.
#:Erik, who worked with ISO/IEC JTC 1/SC 18 standards for four years.
--
http://www.naggum.no/spam.html is about my spam protection scheme and how
to guarantee that you reach me. in brief: if you reply to a news article
of mine, be sure to include an In-Reply-To or References header with the
message-ID of that message in it. otherwise, you need to read that page.
Kent M Pitman
> There were some Europeans who didn't want to be
> forced to use Common Lisp (many countries have a very strong bias in favor
> of using ISO languages).
There was also already Eulisp, and a risk that would supplant CL in
the US and other places in Europe where Eulisp was not used. The
situation was symmetric. Most countries that had an opinion at all had
something they liked. No one was clamoring for a change. The part I
objected to earlier was the implication I perceived that the great big
Imperial US Machine was risking walking over the poor little other
countries and that those companies were protecting themselves from our
aggression by joining in. If anything, the opposite is true: The US
gets only one vote on the international stage and in spite of its size
in economic and military terms is quite handicapped in the
international standards arena because each of our 50 states get only
one vote, while each of the European Community's nations have been
smart enough to resist becoming states, leaving them each with
separate votes. Life is like that and I'm not complaining so much as
I'm saying that it doesn't exactly put someone at risk the US will
single-handedly outvote them. Eulisp, as a European effort, risked
forcing stuff on the US to a much greater degree than vice versa.
All of the previous paragraph is my private opinion, and not
necessarily the opinion of any organization or country.
Rainer Joswig
> I fail to see any positive purposes of ISLisp, although I can see the
> negative purposes of it becoming a standard very clearly.
I agree.
Kent M Pitman
That you two can see negatives does not surprise me and does not
disappoint me. The negatives are there to be seen. That you fail to
understand that some did see positives doesn't surprise me either, but
does make me sad.
In my upcoming book ``Everything I need to know in life I learned by
working on the design of Common Lisp'', I discuss the fact that the
very essence of all civilized behavior in any domain is about learning
not to debate the statement "I find value in x." and to simply accept it.
I have a meta-rule that I use for managing debates. It is not 100% right,
but is right so remarkably often that I find it extremely useful:
When person A sees a feature or problem and person B does not,
person A is right. The failure to see something is rarely a statement
about the thing seen, it is generally a statement about the
more-limited breadth of experience of the person failing to see.
Usually, I find, the failure of well-placed, powerful, or comfortable people
to acknowledge and respect the fact that others are often not as well-placed,
powerful, or comfortable leads to the second set of people being a perpetual
underclass because those who are most in the position to do something that is
merely "kind" don't see the point, since they are in need of no kindness
themselves.
I'm speaking generally about the world as well as specifically about
this situation.
In this case, France identified its need for a standard, probably because of
the needs of ILOG, though in that I'm just speculating. I know that ILOG
could not use either Eulisp or CL, which would be too disruptive to their
base. And they were seeking a simpler intermediate. Likewise, Japan
identified a need for a smaller standard. Among other things, they cited the
sheer expense of translating and using the HyperSpec and a specific need for a
document of about 100 pages.
I mention these facts for anecdotal purposes only. I think that if
the fact that I have mentioned them changes your view of whether their
request was appropriate, then you misunderstand my point about being
able to accept someone's claim that it mattered to them on face value.
My claim is that, in my personal experience, standards groups begin
with people who are interested in solving their own problems and who
have no interest or care in others. They tend to view others'
problems as something they have procedural mechanisms for voting not
to do. I personally did this because I saw others do it and assumed
at the outset of my standards career that this was what it was all
about. At some point, I began to take a different point of view,
which is that my role there was two-fold--(a) to represent my own
organizations needs (i.e., my company when being its corporate rep to
X3J13 or my country when being its national rep to WG16) and (b) to
help, as best I could, others who were trying to achieve needs I did
not have as long as it didn't fundamentally infringe my other
responsibilities. I did this out of a learned sense of compassion as
I came to understand others' needs better but also out of a growing
sense that I would want them to do the same for me if I had a need
they didn't--I wouldn't just want them to walk away having satisfied
their own needs and not caring that I had needs they didn't have.
And finally, I also had learned that sometimes people have needs they
cannot articulate or are not permitted for reasons of confidence to
tell me, but that are nevertheless true needs. Indeed, for all I
know, in some cases the problem is difficulty of language itself; it's
a wonderful thing that I understand English and can rant on and on in
it without being hampered (well, maybe you don't think it's so
wonderful, but indulge me the point here :-), but others in other
languages may have grand thoughts that they can't wholly express to
me. So I regard it as sufficient for them to merely say they have a
reason--I may try to elicit it, but if I can't, that doesn't prove it
is not there.
And then it comes down to a question of whether I have enough personal
respect for them to believe them even when they can't prove it. My
experience has been that academia's model of "I will respect only who
commands my respect" is error-prone and frustrating, and I prefer to
give people more benefit of the doubt than that. That's not to say
I don't still question the issues. That's not to say that I don't
hold tightly to my own organization's needs when it comes to a vote.
But I try to bend where it doesn't cost me overly to do so. And I try
to listen and believe where it doesn't hurt me to do so. And mostly
I try to avoid statements like "I fail to see xxx about yyy"
where I'm pretty sure others have seen xxx because I consider
it more a statement either about my own limited imagination or about
my disrespect for those who have seen xxx, neither of which is very
flattering to me.
These are all just my personal opinions and observations, and no the
official position of any organization I may at times represent.
And being opinions, they are not uniquely determined. You're welcome
to have ones that disagree--in which case I'll do my best to
understand and accept them. (But there is, of course, the consistency
paradox where in trying to be tolerant, I will sometimes appear a
bit intolerant of intolerance. Such is life.)
Oh, and btw, I was just kidding about the book I was writing. It's a
nice idea, but I'm not sure I have the time. I may one day do a book
on philosophy, but it won't have such a narrow title.
Erik Naggum
| That you two can see negatives does not surprise me and does not
| disappoint me. The negatives are there to be seen. That you fail to
| understand that some did see positives doesn't surprise me either, but
| does make me sad.
I appreciate your point of view, Kent, but sometimes, whether something
gets classified as "negative purpose" or "positive purpose" depends a
little bit on one's political point of view. for one person, stopping an
enemy or competitor is perceived as a positive purpose and a value. for
others, it is a negative purpose despite any positive consequences.
fighting an enemy is always cost-only, although it can be cost-effective
compared to caving in, and it thus can (and should) be defended, but that
doesn't make it a _positive_ purpose per se.
as I have a few years of ISO work under my belt mysefl, I'll relate a
story from ISO/IEC JTC 1/SC 18 when ISO 8879 SGML was fighting ISO 8613
ODA for dominance in features and who could satisfy the most users and/or
needs. (since they satisfy completely different markets, this is really
silly, but most wars aren't over reasonable points of disagreement.) at
one point, the ODA feature to represent both a formatted and a logical
structure in the same document annoyed the SGML people enough to invent a
feature they called CONCUR, for concurrent document types. it's a real
kludge, it's dramatically under-specified and introduces a huge number of
problems in processing a document that was not intended to be processed
with CONCUR (quite unlike the ODA feature, which was truly orthogonal).
knowing the people who were attending the dinner over which this feature
was born, I know for a fact that it _had_ no positive purposes. it was a
political move intended only to reduce the perceived "lead" that ODA had
in the European Community at the time, but it had no other use, and has,
to my knowledge, never even been _attempted_ implemented anywhere. when
I implemented my own SGML system, I was also actively discouraged from
implementing it by the same people who got it in there to begin with.
(various misguided users proclaim a "need" for an implementation every
now and then, failing to understand what it could and could not do, and
abandon their request as soon as they do.)
"I value X" is not sufficient to know whether somebody is constructive or
destructive. sometimes, it has "to the exclusion of all competition"
tacked onto it, and is thus a destructive attitude, one which creates
enemies and factions that _have_ to fight each other. (I think I see
that you also argue against this attitude, but not in the context of
statement of what people value, only in how they react to others' values,
real of purported. I think it pertains to the values, and not primarily
to other people's reactions to them.) sometimes, such "values" _are_
needed, especially when stupid people do stupid things that really hurt
other people. (I cling to the belief that smart people who do stupid
things will eventually stop doing them, and will not keep doing them just
to keep from losing face or prestige or somesuch.) some people will make
choices based not on what they _really_ want, only on what they don't
want. getting just _one_ such person into a standards committee is
enough to undermine the whole standards process. some companies (or
countries) put people like that on standards committees on purpose just
to keep from losing their position in the market.
ideally, such petty wars should not occur at the working group level in
ISO, only at the subcommittee (SC) or technical committee (TC) level,
such that wars are fought over complete standards with technical merit,
but those who want to fight dirty seldom respect others enough to keep
this separation clean.
| In my upcoming book ``Everything I need to know in life I learned by
| working on the design of Common Lisp'', I discuss the fact that the very
| essence of all civilized behavior in any domain is about learning not to
| debate the statement "I find value in x." and to simply accept it.
apart from having learned a _lot_ from working within ISO working groups
for a few years that I hope never to get any use out of, I think there's
a difference between positive and negative values of X. "I find value in
X being dead" is still debatable in my probably naive political view, yet
I seem to see such "values" a lot in the political landscapes.
| Usually, I find, the failure of well-placed, powerful, or comfortable
| people to acknowledge and respect the fact that others are often not as
| well-placed, powerful, or comfortable leads to the second set of people
| being a perpetual underclass because those who are most in the position
| to do something that is merely "kind" don't see the point, since they are
| in need of no kindness themselves.
my view is that some people who perceive themselves to be members of the
underclass grow bitter well before their time and seek no other values
but to replace whoever they believe are in power with a view to being in
position to run over _their_ enemies, and if they are doing technical
work in ISO, they are probably very smart folks to begin with, so won't
necessarily make their real purposes overt. not being overly political
(at least not at the time), I saw right through these folks, but also
learned that countering them openly could not work. to fight a covert
agenda takes _better_ covert agendas. occasionally, a good and useful
International Standard rises from this despicable mess. the really good
and useful International Standards, however, come from committees where
nobody sees themselves as members of any underclass. that usually comes
about when nobody in the committee has to fight anybody else, because all
the folks have real values, not ersatz values and hidden agenda.
I have a problem respecting people who know that their "values" are not
going to be approved, so they fight for apparently reasonable ersatz
values that they can tail-coat their real values on before anybody wises
up to their game. I think the question "what do you want?" is legitimate
of people who say "I value X", and if they cannot answer (honestly), then
there's no need to believe them. the diplomatic thing do with people who
lie to your face is to ignore their lies in such a way as to expose them.
however, this probably takes solid experience with getting away with lies
on your own before you can succeed. somehow, I didn't value this part of
the work in ISO. I'm sure some committees are less permeated by this
political climate than others, though, and I'm allowing for optimism to
be true, cautious though I may be.
something makes me feel like a disillusioned lawyer. ick.
#:Erik
Kent M Pitman
> apart from having learned a _lot_ from working within ISO working groups
> for a few years that I hope never to get any use out of, I think there's
> a difference between positive and negative values of X. "I find value in
> X being dead" is still debatable in my probably naive political view, yet
> I seem to see such "values" a lot in the political landscapes.
well, I did mention i have little tolerance for people who value
intolerance, which says a similar thing.
but in the end, i think my point is illustrate best by observing that
islisp did not kill common lisp. so to have killed islisp would be
me valuing something being dead, not stopping people who were trying
to kill CL.
in a pluralistic world, i think there's a lot to be said by
translating dislikes of things into proper labeling.
for example, i don't like smoking. and it's popular among non-smokers
to assert that smoking should be disallowed. but i have advocated a
different course: simply insist on truth in labeling. what bugs me
most about a restaurant that permits smoking is not that they permit
it, but that they tell me they have a "non-smoking area" when they
don't. i want an area that doesn't just keep me from smoking, but
keeps smoke from reaching me. and nothing troubles me at all about a
restaurant saying "we have a non-smoking area". i can just fail to
patronize those. what bothers me is sitting down in an area that i
think is going to be smoke-free, only to find it's not. naively,
everyone would like every space in the world to be of a type that is
compatible with them, but i think that's unreasonable. all i want is
for the spaces that others have to fit gracefully into the same world
as the spaces for me, and for everything to be properly labeled.
because they are not labeled correctly, people frame the discussion
in terms of killing off the other group because they can't find the
comfortable dividing line between them.
usenet newsgroups, for all their problems, label the spaces correctly
and a large number of people who don't agree are accomodated.
this is an example where proper labeling repairs what would otherwise
be a deadly problem. (usenet may also die because some people are
jerks and absent moderation, a few jerks can kill everything. or it
may die because of sheer volume. but my point is that at least
"speaking offtopic" by people with radically different views and
priorities is effectively managed by simply labeling.)
if languages are properly named, i think the tendancy to want them
dead is reduced. yeah, i may still not like c, but at least the fact
that it's a separate community keeps lisp safe. and in a smaller
way, you could argue that the presence of islisp took some pressure
off of CL to change in ways that perhaps it didn't want to change.
the tension to only create a few standards creates most of the problem.
that causes the resource of "controlling the group" to be a critical one
and gives people who don't agree noplace to go. i'd rather standards
groups were easier to create so that people who disagreed would just
get different groups, and let market forces resolve things.
but given that iso is sparing in its creation of standards groups, and
given that i am sometimes asked to share space with people that don't
agree, i think the best one can do is correctly label things. if we
disagree and have to compromise, that's ok--just name the new thing
something new (as we did: islisp) and let the market sort it out.
i think in the problems you were talking about, the fact that they wanted
to use the name SGML is what caused the problem. if the ISO standard
had been called YASGML (in the YACC tradition), perhaps it would have been
easier to be philosophical about the issues, since if (as I suspect
you think) SGML was better off without the changes, then SGML would have
dominated in the market after.
the decision of some governments to prefer ISO standards without
any more information than just "this is an ISO standard" is clearly
also a bug. "standard" does not imply "good". but again, having a
different name for the output helps to combat that and makes people
have to think (as they always should have) "do i want SGML or YASGML?"
as always, this is all just my personal opinion and not necessarily the
official opinion of any organization i might represent.
Rainer Joswig
<pit...@world.std.com> wrote:
> it is generally a statement about the
> more-limited breadth of experience of the person failing to see.
Thanks. ;-)
> In this case, France identified its need for a standard, probably because of
> the needs of ILOG, though in that I'm just speculating. I know that ILOG
> could not use either Eulisp or CL, which would be too disruptive to their
> base. And they were seeking a simpler intermediate. Likewise, Japan
> identified a need for a smaller standard.
Hmm, ILOG is no longer a Lisp vendor (AFAIK). Maybe there is
a lesson to be learned.
> Among other things, they cited the
> sheer expense of translating and using the HyperSpec
A french-specific problem, maybe. ;-)
I wonder how many people have looked into the ISLisp standard docs.
Not that its value solely depends on this number - but it
might be an indicator of the interest in ISLisp.
Jeff Dalton
> Jeff Dalton <je...@gairsay.aiai.ed.ac.uk> writes:
>
> > I guess what I wondering at this point is whether you agree with the
> > following, or not, as an answer to "So why was the [ISO] standard
> > defined in the first place?:
> >
> > Because there was a faction that didn't want Common Lisp to become
> > an ISO standard, and the only way they could prevent it was by
> > defining an alternate standard.
> >
> > For my part, I do not agree that the standard was defined in the first
> > place for that reason.
>
> Well, I think there were Common Lisp factions (not just in the US)
> that didn't want Eulisp to become an ISO standard either. I would
> never phrase it in a one-sided way like you have.
It's not *my* phrasing. I was quoting someone else. You responded
downstream, and so I'm wondering whether you agree with it or not.
(I disagreed with the claim above, and you responded to me, so
I wanted to know your view on what I took to be the point at issue
in this branch of the discussion.)
> Rather than try to put words in my mouth and then disagree with them,
I am not trying to put words into your mouth.
> why don't you just say what you think and leave it to me to disagree
> if I want to. Or, if there's an important reason I need to speak
> first, say what that reason is.
One reason I would like you to address the claim given above directly
is that otherwise it might be taken as true, given who said it
(barmar, if memory serves). (He usually knows what he's talking about
and indeed is usually right.) And if I'm wrong, and it is true,
I'd like to know. You are in a better position to know whether it's
true or not than I am.
> I've already volunteered enormously
> more info on this than I am comfrotable offering to an international
> audience of unknown compositio. As I said before, it's very very very
> difficult for me to respond to these questions at all. It takes me a
> lot more time and energy editing my reply than I would like to spend,
> but I am also not comfortable seeing statements semi-attributed to me
> (such as above) and so I feel forced to comment where I don't always
> want to.
I did not at all semi-attribute it to you. I assumed, parhaps
mistakenly, that you would remember where it came from. I apologise
for not making things clearer.
-- jd
Jeff Dalton
> | Could someone shortly explain the major differences between Common Lisp
> | and the current ISLisp draft?
>
> for what it's worth, ISO/IEC 13816:1997 "Information technology --
> Programming languages, their environments and system software interfaces
> -- Programming language ISLISP", has been passed. it's 126 pages long.
>
> the major difference? Common Lisp is an "a posteriori" standard, while
> ISLisp is an "a priori" standard, i.e., for Common Lisp, experiences from
> the real world preceded the creation of the standard, while in the ISLisp
> case, the standard precedes experiences from the real world.
I don't think that's entirely fair. Some things were put into Common
Lisp when there was not much real-world experience with those specific
things, only with similar things. CLOS contains some examples,
and I suspect that a look through the cleanup issues will find some
that were passed before the real-world experience.
For ISLISP, there was no real-world experience with ISLISP, but it
was a fairly conservative language, so that real-world experience
with a number of other Lisps was relevant.
-- jd
Kent M Pitman
I think I had not seen barmar's post, which is why I was confused
about the fact you were posting about it.
Anyway, in spite of my being confused, I hope it was clear what my
position was.
Certainly some might not agree that the best way to sum things up is
to say "the reason is that it resulted from the process", but I think
that's a much neglected way of explaining things in a political
process.
Democratic voting machines are a bit like perceptrons: each individual
component can do its job without the whole functioning intelligently.
And, in particular, both are incapable of composing small data into
large data "consistently". Given internally consistent choices A/1
and B/2 and asked to vote A vs B and 1 vs 2 independently, both
perceptrons and democratic engines will generate A/2 and B/1 as
possible outcomes. And sometimes that means everyone is unhappy
in spite of best intentions. Of course, sometimes they produce
better outcomes, and then we take that as evidence that the engine
works. :-)
I don't know what possessed someone to make an ISO work item in the
first place. It was probably well-intentioned, but may have been a
bad idea. I don't know why people approved the work item. I don't
know why those who chose to join did so. And I sat through meeting
after meeting in which it seemed clear to me that no one was there for
the same reason. So the outcome seemed to me to be the process of
counting votes made by people with conflicting goals.
To answer your question any more clearly, though, I would have to
opine about others motives for doing things. I have my opinions, as
anyone would. But I'm trying hard not to voice them, since it is not
my place. I apologize for the fact that this leaves a big gaping hole
in my answer.
(Insert standard disclaimer about this all being my own personal
opinion and not that of any company or country.)
Kent M Pitman
> > the major difference? Common Lisp is an "a posteriori" standard, while
> > ISLisp is an "a priori" standard, i.e., for Common Lisp, experiences from
> > the real world preceded the creation of the standard, while in the ISLisp
> > case, the standard precedes experiences from the real world.
>
> I don't think that's entirely fair. Some things were put into Common
> Lisp when there was not much real-world experience with those specific
> things, only with similar things. CLOS contains some examples,
> and I suspect that a look through the cleanup issues will find some
> that were passed before the real-world experience.
FWIW, I think just the opposite.
CL did not add much of anything that there wasn't extensive real world
experience with. In some cases, there was so much experience that the
syntax cnoflicted, and some new things were tried. In spite of its
size, though, I think the individual choices were largely
tried-and-true and quite conservative. Indeed, many of the parties
involved would not have voted to approve were it otherwise. And
besides, there were sample portable implementations of CLOS,
Conditions, Iteration, and PPRINT available and widely tested before
the standard closed. The only truly new item was the macro
environment stuff, which was removed after CLTL2 because we couldn't
get it to work. And the Symbolics Common Lisp implementation, which
was essentially complete and correct, was available commercially 2
years before the standard was formally approved and 3 years before it
was available for purchase. Many other implementations that were very
close were available at that time, too, and have continue to converge.
> For ISLISP, there was no real-world experience with ISLISP, but it
> was a fairly conservative language, so that real-world experience
> with a number of other Lisps was relevant.
ISLISP is indeed small, and I suppose implicit in that is some kind of
conservatism, but it didn't have existing customers to worry about and
really it's hard to tell yet if the decisions made were adequately
conservative. I think the jury is still out.
For example, I personally think the absence of both a module system
and a package system is not a conservative approach because I do not
think inaction is inherently conservative. I would have preferred
a package system to nothing, but there was essentially no support
for that.
I also personally think that the decision to follow the scheme model
of explaining syntax syntactically instead of using forms is not a
strong one, and under heavy use might result in confusion.
And I think the error system, such as it is, is ... I'm struggling
for a word ... "naive" is the only one that comes to mind. There
is the sense that type errors will be caught but not a lot of talk
about how. It remains to be seen if efficient math can be done
given that there was a refusal on the part of some to consider my
suggestion of including declarations, and yet absent declarations
and a low/high safety notion, you're forced to do runtime type
checking in the math if your compiler can't fully type-inference.
But again, my point is that the decision not to include declarations
and type inference is not automatically "conservative" since it's
at odds with fast code. We might have said if you pass the wrong
args, you deserve to lose, but some were uncomfortable with that.
But instead we said "an error shall be signalled" in all cases of
domain errors.
My point is that I think CL was much more conservative than ISLISP.
I respect the fact that Jeff thinks otherwise; he's no dummy and
doesn't ake positions for no reasons. But it's important to me that
people see that questions of "aesthetics" and "conservatism" are not
uniquely determined, but are the result of various underlying
assumptions and priorities that one beings with. Since mine are
probably different than his, we reach different conclusions. But
thanks to the very thoughtful designers of English, we both get to
claim use of vague terms like aesthetic, conservative, etc. :-)
These are, as always, just my personal opinions and not the official
position of my company or country.
Erik Naggum
| I wonder how many people have looked into the ISLisp standard docs. Not
| that its value solely depends on this number - but it might be an
| indicator of the interest in ISLisp.
FWIW, nobody in Norway has ordered a copy of the approved standard.
those of us on the national ISO/IEC JTC 1/SC 22 mailing list got the DIS,
but we offered no vote on it, and I was the only one who had read it in
time for the vote, anyway.
ISO headquarters in Geneva (see WWW.ISO.CH) can give you the exact number
of copies of the standard they have sold if you call them.
Marc Wachowitz
> I wonder how many people have looked into the ISLisp standard docs.
> Not that its value solely depends on this number - but it
> might be an indicator of the interest in ISLisp.
While I didn't buy the formal standard, I did read carefully several of
the electronically published free intermediate documents, since quite
early in its development, including the last one [1], from which the
standard was derived. If it had developed more useful for my interests,
I would even have implemented it (and made it available). Unfortunately,
several IMO quite important features for serious usage in non-trivial
programs are not only lacking, but also hard to add as a true superset
of ISLisp. I've tried to design a static (i.e. compile-time-only) module
system providing separate compilation, name space management, and hints
for optimization on top of ISLisp, which should work well with its form of
macros, but didn't come up with anything I'd really want to use both in
relatively small "scripts", as a simple, orthogonally defined and modular
extension language in otherwise non-Lisp applications, and in large Lisp
applications - all with the potential for good performance on ordinary
hardware, with ordinary operating systems, and without needing a heroic
compiler which either knows the whole program in advance or re-optimizes
code at or after load time. What I hoped for would have been similar to
Henry Baker's ideas in "Critique of DIN Kernel Lisp Definition 1.2" [2],
and this is still something I'd call my Lisp Dream. Sure, I don't strictly
"need" a Lisp standard to implement something like that, but I don't have
the illusion that I, just a single person doing this in my free time, am
the best designer, implementor and manual/tutorial writer for a Lisp which
would fulfill such interests. Given many existing attempts to provide
a selection of similar traits as extensions of Scheme, and an appearant
growth of interest in "scripting/extension languages" (of which most are
quickly revealing their poor design as soon as some programs get complex,
or should become reusable modules of a larger infrastructure, which tends
to happen quite frequently, despite the more optimistic expectations of
people to keep things small - at the moment, I see only Python as working
reasonably well for larger systems), I'm even confident that there are a
lot of developers and projects which could make good use of such a system.
EuLisp also showed some movement towards such goals, but it seems that it
somehow got stalled (still lacking a seriously usable macro system and a
clear specification of translation phases and their dependencies, among
other things).
[1] ftp://ftp.harlequin.co.uk/pub/kmp/iso/v20/
[2] ftp://ftp.netcom.com/pub/hb/hbaker/CritLisp.html
-- Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de>
Jeff Dalton
> Jeff Dalton <je...@gairsay.aiai.ed.ac.uk> writes:
>
> > > the major difference? Common Lisp is an "a posteriori" standard, while
> > > ISLisp is an "a priori" standard, i.e., for Common Lisp, experiences from
> > > the real world preceded the creation of the standard, while in the ISLisp
> > > case, the standard precedes experiences from the real world.
> >
> > I don't think that's entirely fair. Some things were put into Common
> > Lisp when there was not much real-world experience with those specific
> > things, only with similar things. CLOS contains some examples,
> > and I suspect that a look through the cleanup issues will find some
> > that were passed before the real-world experience.
>
> FWIW, I think just the opposite.
>
> CL did not add much of anything that there wasn't extensive real world
> experience with.
Well, I'm not going to go through the cleanup issues right now,
and I haven't thought about the cleanups in detail at all for
years, but I can immediately think of one, and I'm pretty sure
there were quite a few others. We also came pretty close to
passing proclaim-lexical, even though there was no (certainly
no tried-and-tested) implementation of what was proposed.
And I don't think there was much, if any, real-world experience
with CLOS at the time it was approved by X3J13. The whole
standardization process took so long that much more had
happened by the time there was finally a standard, but the
language design work was not post substantial real-world
experience, so far as I can recall.
But in any case, I am not arguing that CL is an a priori standard,
only that "Some things were put into Common Lisp when there was not
much real-world experience with those specific things, only with
similar things."
> > For ISLISP, there was no real-world experience with ISLISP, but it
> > was a fairly conservative language, so that real-world experience
> > with a number of other Lisps was relevant.
>
> ISLISP is indeed small, and I suppose implicit in that is some kind of
> conservatism, but it didn't have existing customers to worry about and
> really it's hard to tell yet if the decisions made were adequately
> conservative. I think the jury is still out.
I think it's conservative in a fairly obvious sense, namely that
the constructs in it were pretty much ones we all knew could be
implemented without serious problems and clashes and which were
very similar to things in existing Lisp family languages.
And the issue here is a priori vs a posteriori, so that
"conservative" should be understood in a relevant sense.
> For example, I personally think the absence of both a module system
> and a package system is not a conservative approach because I do not
> think inaction is inherently conservative.
Putting in a module system would have been a priori, I would say.
Omitting both was not. And I would say it was conservative too.
It was even perhaps "reactionary", undoing part of the CL
"revolution". :-)
> But again, my point is that the decision not to include declarations
> and type inference is not automatically "conservative" since it's
> at odds with fast code.
Humm. I think you are using a meaning of "conservative" that I
do not understand.
-- jd
Jeff Dalton
> In article <sfwhfyq...@world.std.com>, Kent M Pitman
> <pit...@world.std.com> wrote:
> > Among other things, they cited the
> > sheer expense of translating and using the HyperSpec
> A french-specific problem, maybe. ;-)
No, that was the *Japanese*:
Likewise, Japan identified a need for a smaller standard. Among
other things, they cited the sheer expense of translating and using
the HyperSpec and a specific need for a document of about 100 pages.
-- jd
Harvey J. Stein
> In my upcoming book ``Everything I need to know in life I learned by
> working on the design of Common Lisp'', I discuss the fact that the
> very essence of all civilized behavior in any domain is about learning
> not to debate the statement "I find value in x." and to simply accept it.
That seems a bit extreme. I can think of lots of grizzly and immoral
things to replace X with and I think it would be appropriate to debate
or take action against such statements.
As for a programming example, what about "I find value in always using
goto instead of looping constructs". I think it would be appropriate
and advantageous to both parties to debate such a statement. Perhaps
the holder of such a view will learn that his preference is based on
some mistaken assumptions. Perhaps the debator of such a view will
learn something about goto.
Simple acceptance isn't the path to civilized behavior. It's the path
to no behavior at all.
--
Harvey J. Stein
BFM Financial Research
hjs...@bfr.co.il
Kent M Pitman
> And I don't think there was much, if any, real-world experience
> with CLOS at the time it was approved by X3J13.
PCL, the basis of most present-day implementations of CLOS, had years
of testing before the standard was approved. Symbolics Genera was not
PCL-based and was an independent confirmation that the idea was sound.
I left Symbolics when laid off in late 1992, two years before the
standard was approved, and I took with me (properly purchased) a
Macivory Model 3 running Genera 8.3 with CD ROM files dated Oct 92
that were part of a released product and that wasn't even the first
release of CLOS. I think Symbolics had had some commercial version of
it for at least 2 years before that. That's a lot of testing, compared
to what anything in ISLISP received. In 1990 at the EUROPAL conference,
I won a copy of Procyon Common Lisp for writing a Best Paper. It had
CLOS in it--very centrally featured. There were a lot of opportunities
to use and condemn CLOS. No one tried to condemn it. In December 1992,
when I came to Harlequin, Apple and Harlequin had begun work on yet
another language (Dylan) which was based on the CLOS experience, and
though it tried to do some things differently, it was heavily based on
CLOS. Where it wasn't, the rejection mostly wasn't a rejection of
CLOS per se, it was a rejection of CLOS' introspective features. But
that has always been a strong part of Lisp, and is more like a cultural
divide between Lisp and Dylan, not a criticism of Lisp a priori (well,
not more than any cutlural divide is :-). I don't think Apple would
have invested money in building on the CLOS model if it was "untested".
> The whole
> standardization process took so long that much more had
> happened by the time there was finally a standard, but the
> language design work was not post substantial real-world
> experience, so far as I can recall.
No, but it was never intended that CLTL2 be released. Steele did that
on his own and the standards group cannot be held responsible. We,
many of us, actively tried to talk him out of it. From the standard's
point of view, the first appearance was 1994 and up until that time,
anyone could have voted NO saying there was a problem. We had passed
feature freeze, but that was only a convention. We added a few and
removed many features after feature freeze when they were seen
unworkable. The removal of the declaration facility is an example of
our willingness to back out of stuff we weren't sure of. And the
omission of the MOP was an example of our willingness to not just add
CLOS wholesale untested. (The main reason for not adding the MOP is
that it was unfair to some vendors, not that it was unworkable. It
was fine for PCL-based implementations where the MOP described what
actually happened, but it was not good for implementations like
Symbolics where the MOP basically offered a plan for wholly
reimplementing an existing system in an incompatible way at huge
expense. And since the secret, real purpose of standards groups is
to avoid antitrust lawsuits, that's a non-trivial issue.)
> But in any case, I am not arguing that CL is an a priori standard,
> only that "Some things were put into Common Lisp when there was not
> much real-world experience with those specific things, only with
> similar things."
For varying values of "much". :-) If you're saying anything at all
using this vague term, what you're really saying is that the total
usage of CL was so enormous that comparatively the usage was small.
But there were years of commercial products.
> > > For ISLISP, there was no real-world experience with ISLISP, but it
> > > was a fairly conservative language, so that real-world experience
> > > with a number of other Lisps was relevant.
> >
> > ISLISP is indeed small, and I suppose implicit in that is some kind of
> > conservatism, but it didn't have existing customers to worry about and
> > really it's hard to tell yet if the decisions made were adequately
> > conservative. I think the jury is still out.
>
> I think it's conservative in a fairly obvious sense, namely that
> the constructs in it were pretty much ones we all knew could be
> implemented without serious problems and clashes and which were
> very similar to things in existing Lisp family languages.
> And the issue here is a priori vs a posteriori, so that
> "conservative" should be understood in a relevant sense.
I can't say this strongly enough: Constructs are not what matter.
Semantics, not name, matters. Having + is not inherently conservative.
It depends on how you define +. And saying that + always detects bad args
is quite a burden on efficient semantics.
> > For example, I personally think the absence of both a module system
> > and a package system is not a conservative approach because I do not
> > think inaction is inherently conservative.
>
> Putting in a module system would have been a priori, I would say.
> Omitting both was not. And I would say it was conservative too.
> It was even perhaps "reactionary", undoing part of the CL
> "revolution". :-)
>
> > But again, my point is that the decision not to include declarations
> > and type inference is not automatically "conservative" since it's
> > at odds with fast code.
>
> Humm. I think you are using a meaning of "conservative" that I
> do not understand.
I'm using "conservative" in the sense that it minimizes financial risk
to the community (in my estimation). There is cost to not providing
something, and there is cost to providing something you might have to
back out of. The "conservative" approach minimizes the expected cost
times the probability of the occurrence. (But no, I didn't do a
rigorous numerical computation. I'm just making broad statements,
just as I imagine you are.)
All of the above is just my personal opinion, and not the official
Kent M Pitman
> Kent M Pitman <pit...@world.std.com> writes:
>
> > In my upcoming book ``Everything I need to know in life I learned by
> > working on the design of Common Lisp'', I discuss the fact that the
> > very essence of all civilized behavior in any domain is about learning
> > not to debate the statement "I find value in x." and to simply accept it.
>
> That seems a bit extreme. I can think of lots of grizzly and immoral
> things to replace X with and I think it would be appropriate to debate
> or take action against such statements.
The nice thing about general rules is that they are not fully general.
I don't discount what you say--but the need to make an exception
should never be a reason not to develop some good, general rules.
Except in jovial conversations, I don't think much can be done with
Lisp that's immoral. Of course, if you mean applications can be
written that are immoral, THAT can probably be done. But it's the
application, not the code, that's likely immoral.
> As for a programming example, what about "I find value in always using
> goto instead of looping constructs". I think it would be appropriate
> and advantageous to both parties to debate such a statement. Perhaps
> the holder of such a view will learn that his preference is based on
> some mistaken assumptions. Perhaps the debator of such a view will
> learn something about goto.
I think the key is that if there is someone party to the discussion
who thinks goto is sometimes good (and btw, I'm in that camp), then
that person's opinion should be taken seriously and not labeled (as
you say) "immoral".
(Incidentally, I think gotos are ok EVEN THOUGH my mid-term exam at
MIT in compiler design long ago had a question on it that said "Gotos
are (a) good (b) bad." I guessed from the form of the question that
(b) must be right. But disagreements over computer religion/dogma of
this kind are ultimately why I ended with a degree in Philosophy
rather than Computer Science.)
> Simple acceptance isn't the path to civilized behavior. It's the path
> to no behavior at all.
Acceptance of a belief is not the same as acceptance of an action.
You may think eating pork is immoral, but before you engage in an open
discussion with someone who thinks eating celery is immoral and eating
pork is the entry to heaven, you'd better be ready to engage his
personal beliefs with the same deep conviction that you expect him to
engage your own. Maybe he wants human sacrifice, and maybe then you
draw a line, but the line must be drawn in a way that is not based on
the "obvious rightness" of your belief or the "obvious wrongness" of
his belief, but on some neutral criterion that descends from neither
belief. You may be able to convince him not to kill people, but you cannot
convince a person not to believe what he believes. If you insist that he
not only behave a certain way, but think a certain way, you've lost your
bargaining posture.
I was not speaking about "action" in the remark you quoted, I was
speaking about "respect". In a world full of religions, ethics, and
moralities that diverge, it is important that while holding to our own
beliefs we also respect that others have theirs. And it is critical
to our own survival that we don't decide who wins on "harmless"
matters by who is in the majority, because we might not find ourselves
in the majority one day and we would like those "harmless" things we
hold dear to be rspected by the then-majority.
I DIDN'T say "do anything anyone asks". I spoke specifically of acts
I could take that did not perturb my responsibility to my own group's
needs and were simply not harmful to my group. (If you think immoral
things could come of that, you must presuppose my group's needs to be
immoral, since otherwise I'd assume an immoral act would harm my
country's needs and would be something I would stand against.) I said
to begin by the assumption that you would not rule out something just
because you yourself don't need it. That's a fair sight short of
accepting everything that works against what you need. "don't need
it" dosn't imply "can't tolerate it". In my experience, getting
people to bargain on the hard things is not a problem. What IS a
problem, in practice, is getting people to acknowledge TRIVIAL needs
of others which just don't seem important enough for someone else to
care. What IS a problem is getting the comfortable folk to bend at
all, because they are strong enough not to bend even though bending
would not cost them.
In the case of ISLISP, to date it has hurt no one that anyone can
discern. Yet some screamed and yelled that it would be awful, and
feared it. By engaging it in a way that allowed us to finish the
standard, working to contain the specific problems that would have
been a problem, the result caused no great harm. If we had instead
insisted it should not have gone ahead, it might have stopped there.
But the perceived need of some would not have gone away. Some of our
community might have lost face, and that would have hurt Lisp. Other
actions hostile to other Lisps might have been taken, and that might
have hurt Lisp. It might have led to a(n even greater) rift among
Lispers--that could have been bad. And it could have led to a
perception among outsiders that Lisp was not standard. Or it could
have led to (or been twisted to) a perception that Lisp had failed.
Any of those outcomes would have been far worse. Engaging it respectfully
seemed, to me at least, the cheapest and least risky alternative.
All of the above is just my personal opinion and not the formal position
David H Wild
Harvey J. Stein <hjs...@bfr.co.il> wrote:
> That seems a bit extreme. I can think of lots of grizzly and immoral
> things to replace X with and I think it would be appropriate to debate
> or take action against such statements.
Could the value be negative? :-))
--
__ __ __ __ __ ___ _____________________________________________
|__||__)/ __/ \|\ ||_ | / Acorn Risc_PC
| || \\__/\__/| \||__ | /...Internet access for all Acorn RISC machines
___________________________/ dhw...@argonet.co.uk
Reini Urban
>Lisp that's immoral. Of course, if you mean applications can be
>written that are immoral, THAT can probably be done. But it's the
>application, not the code, that's likely immoral.
loop is perfectly immoral. especially the usage in lisp introductory
texts.
---
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
Hannu Rummukainen
> [2] ftp://ftp.netcom.com/pub/hb/hbaker/CritLisp.html
That's quite an interesting article there. I wonder which current Lisp
systems would come closest to Mr. Baker's ideal. Is anyone seriously
working in such a direction, i.e. sacrificing backwards compatibility
for parallelism and heavy-duty optimizations?
Hannu Rummukainen
Jeff Dalton
> Jeff Dalton <je...@gairsay.aiai.ed.ac.uk> writes:
>
> > And I don't think there was much, if any, real-world experience
> > with CLOS at the time it was approved by X3J13.
>
> PCL, the basis of most present-day implementations of CLOS, had years
> of testing before the standard was approved.
Years of testing, real-world experince -- we're not talking
about the same thing here.
> Symbolics Genera was not
> PCL-based and was an independent confirmation that the idea was sound.
A number of people were unconvinced by lisp machine implementations,
because they thought there were efficiency problems on conventional
machines that could be avoided on LMs.
I could go on to make counterpoints to the rest of what you say
in this paragraph, but it would be a pain to type it all in, and
I don't have time right now. Besides, it shouldn't matter all that
much anyway. All I'm saying is that calling ISLISP a priori
and CL a posteriori is an unfair oversimilification. ISLISP was
going out on a limb with untested new ideas. It was "conservative"
in the sense of sticking with things that were pretty well tested
and familiar. Moreover, on the CL side, things were put in that
had not yet been subjected to extensive real-world experience,
and in some cases that had not yet been subjected to any
real-world experience. This is not to say CL was going out
on a limb either. There were always good reasons to think the
things that were put in would work.
When we turn to the existence of implementations, there may have
been an implementation of ISLISP for all I know. But in any
case, it was pretty clear to implement it, and what the language
would be like. On the Common Lisp side, I wonder how many full,
conforming implementations there are even today. I now that
at least in one of the commercial CLs I use, some things have
only recently switched to the ANSI CL way. (I haven't tried
to do a comprehensive survey, just noticed some things as they
came up.)
Now, you something about what happened in 1992, and 1990.
But how many full, conforming CLOS implementations were
there on the say CLOS was approved by X3J13 Because one
of the things to consider here is: how much real-world
testing had been done when things were put into the language?
Was that part of the language design being done before or
after substantial amounts of real-world experience?
> > The whole
> > standardization process took so long that much more had
> > happened by the time there was finally a standard, but the
> > language design work was not post substantial real-world
> > experience, so far as I can recall.
>
> No, but it was never intended that CLTL2 be released.
Did I say it was intended? No.
> Steele did that
> on his own and the standards group cannot be held responsible.
So what? I haven't said anything about CLTL2.
> We,
> many of us, actively tried to talk him out of it. From the standard's
> point of view, the first appearance was 1994 and up until that time,
> anyone could have voted NO saying there was a problem.
Only minor changes were made towards the end, not that I'm
even saying anything to the contrary.
And so on as you continue to argue against the case you wish
I'd made but didn't. :-)
> > But in any case, I am not arguing that CL is an a priori standard,
> > only that "Some things were put into Common Lisp when there was not
> > much real-world experience with those specific things, only with
> > similar things."
>
> For varying values of "much". :-) If you're saying anything at all
> using this vague term, what you're really saying is that the total
> usage of CL was so enormous that comparatively the usage was small.
> But there were years of commercial products.
You either want to respond to what I said, which I quoted above,
or to random, more extreme, silly things I didn't say. If what I
said wasn't "anything at all", then you should't need to respond
to it.
Re: "conservative"
> I can't say this strongly enough: Constructs are not what matter.
> Semantics, not name, matters. Having + is not inherently conservative.
> It depends on how you define +. And saying that + always detects bad args
> is quite a burden on efficient semantics.
Which, so far as I can tell, has almost nothing to do with anything
I said. And, amazingly enough, I too think it's semantics, not name
that matters, and that required checking (modulo type inference)
can have an efficiency cost.
> I'm using "conservative" in the sense that it minimizes financial risk
> to the community (in my estimation).
That isn't a standard meaning for "conservative", though.
-- jd
Erik Naggum
| All I'm saying is that calling ISLISP a priori and CL a posteriori is an
| unfair oversimilification.
I'd love to see a _fair_ oversimplification one day, too, but in the
meantime, the question is pragmatic: does this oversimplification yield
any valuable insight or understanding of a complex issue? I say yes,
because it is the essence of the two approaches, no matter how many
_examples_ you can find to the contrary. however, just as stating any
opinion at all about Lisp will be branded "unfair" by at least one
person, and you're quite often that person, Jeff, most of the time, it's
worth the trouble of stating opinions.
| > I'm using "conservative" in the sense that it minimizes financial risk
| > to the community (in my estimation).
|
| That isn't a standard meaning for "conservative", though.
"conservative, adj, ... 3 a: tending or disposed to maintain existing
views, conditions, or institutions: traditional, b: marked by moderation
or caution."
-- Merriam-Webster's Collegiate® Dictionary
Harley Davis
>| All I'm saying is that calling ISLISP a priori and CL a posteriori is an
>| unfair oversimilification.
>
> I'd love to see a _fair_ oversimplification one day, too, but in the
> meantime, the question is pragmatic: does this oversimplification yield
> any valuable insight or understanding of a complex issue? I say yes,
> because it is the essence of the two approaches, no matter how many
> _examples_ you can find to the contrary. however, just as stating any
> opinion at all about Lisp will be branded "unfair" by at least one
> person, and you're quite often that person, Jeff, most of the time, it's
> worth the trouble of stating opinions.
Having witnessed some part of the action, I would say it's fair to
characterize ISLISP as a political compromise, differing enough from any
existing dialect or implementation that it was unlikely to be adopted by any
major Lisp vendor in a short period of time. I did not detect much desire
on the part of any of the participating vendors to implement and market
ISLISP, although careful effort was paid to making sure it would not be an
undue burden to implement it in the context of existing implementations if
the vendors so desired.
Someone else tried to link France's insistence in ISO on a non-Common Lisp
standard with ILOG's exit from the Lisp market. Having also witnessed this
scene pretty closely, I would say the events were pretty much entirely
independent:
* France's insistence on something other than Common Lisp was based
primarily on a large existing user base for Le-Lisp and, secondarily, a fear
that Common Lisp would not provide a sound technical basis for a
commercially viable Lisp with a reasonable number of vendors and a large
user community. I think the shakeout in the Lisp vendor group and general
shrinking of the user community has borne this out, although I'm pretty sure
that no other standardization strategy would have improved this situation
substantially.
* Ilog's exit from the Lisp market had a lot more to do with more
interesting and much larger opportunities elsewhere than any particular
deficiency in our Lisp implementations and sales, combined with a lack of
any fundamental mission to be a language supplier at all. (ILOG is
primarily a library vendor in graphics and optimization; Lisp was a useful
platform in the early stages of the company because it provided a good
foundation for the primary business.)
-- Harley
Jeff Dalton
>
> * Jeff Dalton <je...@gairsay.aiai.ed.ac.uk>
> | All I'm saying is that calling ISLISP a priori and CL a posteriori is an
> | unfair oversimilification.
>
> I'd love to see a _fair_ oversimplification one day, too,
Some oversimplifications have no component of fairness or
unfairness, if you want to be pedantic about it.
> but in the
> meantime, the question is pragmatic: does this oversimplification yield
> any valuable insight or understanding of a complex issue?
Or does it mislead and distort?
> I say yes,
> because it is the essence of the two approaches,
No it isn't.
> however, just as stating any
> opinion at all about Lisp will be branded "unfair" by at least one
> person, and you're quite often that person, Jeff,
Nonsense. It's actually fairly uncommon to see opinions about
Lisp branded "unfair", and when it does happen, I am seldom
the person who does it.
> | > I'm using "conservative" in the sense that it minimizes financial risk
> | > to the community (in my estimation).
> |
> | That isn't a standard meaning for "conservative", though.
>
> "conservative, adj, ... 3 a: tending or disposed to maintain existing
> views, conditions, or institutions: traditional, b: marked by moderation
> or caution."
> -- Merriam-Webster's Collegiate® Dictionary
And does it say "minimizes financial risk"? No.
Of course, minimizing financial risk can be, and perhaps even
typically is, conservative; but it's not *conservative by
definition*.
Amusing quote re the use of dictionaries to prove points:
It's easy to prove that dictionaries have their limits: look up the
definition of "dog". Any definition will probably be incompatible
with one or more of the following: "dead dog", "three-legged dog",
"space alien dog", "ceramic dog", "three-headed dog".
[Weemba, back in 1992]
-- jd
