From: Daniel R. Levy
Subject: Re: lisp (was: Compatibility with EBCDIC)
Date:
Message-ID: <1880@ttrdc.UUCP>
In article <····@utzoo.UUCP>, ·····@utzoo.UUCP (Henry Spencer) writes:
> > Remember, very few people have to distort Lisp to put it on a new
> > architecture.
> Yeah, because they're distorting it to suit their own ideas already -- name
> three Lisp implementations that accept *exactly* the same language! :-)
I'm not sure what sense this makes. Are there even three C or three FORTRAN
implementations which accept *exactly* the same language????? Are lisps
REALLY so diverse (disclaimer: I known nothing about lisp except that it
is written using Lots of Insipid Silly Parentheses :-) ) that they don't
even accept a mutual subset of the language?
--
|------------Dan Levy------------| Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
| an Engihacker @ | vax135}!ttrdc!ttrda!levy
| AT&T Computer Systems Division | Disclaimer: i am not a Yvel Nad
|--------Skokie, Illinois--------|
From: Kenneth Ng
Subject: Re: lisp (was: Compatibility with EBCDIC)
Date:
Message-ID: <1022@argus.UUCP>
In article <····@ttrdc.UUCP>, ····@ttrdc.UUCP (Daniel R. Levy) writes:
[edit on different implementations of Lisp]
> I'm not sure what sense this makes. Are there even three C or three FORTRAN
> implementations which accept *exactly* the same language?????
Hm. If you write something in FORTRAN 2, it will be accepted by FORTRAN 4,
FORTRAN 66, and FORTRAN 77. But I think that's cheating a bit, since the
languages were designed to be upward compatible. Note: I have not tried
*ALL* the language features of FORTRAN 2 (the few that there are). When
I started college I ran a couple decks from a high school FORTRAN 2
program, and it ran on the ones here.
> |------------Dan Levy------------| Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
> | an Engihacker @ | vax135}!ttrdc!ttrda!levy
> | AT&T Computer Systems Division | Disclaimer: i am not a Yvel Nad
> |--------Skokie, Illinois--------|
Kenneth Ng: Post office: NJIT - CCCC, Newark New Jersey 07102
uucp !ihnp4!allegra!bellcore!argus!ken *** NOT ···@bellcore.uucp ***
bitnet(prefered) ···@orion.bitnet
From: Mike (My watch has windows) Meyer
Subject: Re: lisp (was: Compatibility with EBCDIC)
Date:
Message-ID: <4930@jade.BERKELEY.EDU>
[Followups have been pointed to comp.lang.misc.]
In article <····@argus.UUCP> ···@argus.UUCP (Kenneth Ng) writes:
<> I'm not sure what sense this makes. Are there even three C or three FORTRAN
<> implementations which accept *exactly* the same language?????
<
<Hm. If you write something in FORTRAN 2, it will be accepted by FORTRAN 4,
<FORTRAN 66, and FORTRAN 77. But I think that's cheating a bit, since the
<languages were designed to be upward compatible. Note: I have not tried
<*ALL* the language features of FORTRAN 2 (the few that there are). When
Back in the dark ages (when I was in college :-), I had access to four
(or was it five?) FORTRAN compilers, *all* based on FORTRAN IV.
Given any two, I could write code that would compile in either one but
not the other, or produce different results if it ran on both. In many
cases, I could also write code that would compile & run on one, and
die on the others.
The compilers in question? VAX/VMS FORT, IBM/MVS FORTH and WATFIV,
PDP-11/??? f4 running under v6 unix.
So much for FORTRAN being the same. But at least with it, you could
write code that would run on all four. The LISP implementations
available at the same time didn't have the same syntax for defining
functions, or addition, or ...
Then again, it was pretty easy to write LISP code in one so that it
would accept the others. Not so true for FORTRAN.
<mike
--
Lather was thirty years old today, Mike Meyer
They took away all of his toys. ···@berkeley.edu
His mother sent newspaper clippings to him, ucbvax!mwm
About his old friends who'd stopped being boys. ···@ucbjade.BITNET
From: bill coderre
Subject: Re: lisp (was: Compatibility with EBCDIC)
Date:
Message-ID: <6117@apple.UUCP>
In article <····@argus.UUCP>, ···@argus.UUCP (Kenneth Ng) writes:
> Hm. If you write something in FORTRAN 2, it will be accepted by FORTRAN 4,
> FORTRAN 66, and FORTRAN 77.
Common Lisp is much better than that! It has all the features of
EVERY lisp ever, so no matter which Lisp you used, your program will run!!!
(Please, throw rotten tomatoes, crufty veggies, anything soft, just
DON'T THROW MONEY! It hurts!)
Have a *nice* day.................................................bc
From: John P. Nelson
Subject: Re: lisp (was: Compatibility with EBCDIC)
Date:
Message-ID: <4307@teddy.UUCP>
> Are lisps
>REALLY so diverse (disclaimer: I known nothing about lisp except that it
>is written using Lots of Insipid Silly Parentheses :-) ) that they don't
>even accept a mutual subset of the language?
Implementations of lisp can have WILDLY different syntax. The
difference between "Common Lisp" and "Scheme" is huge. The syntax (the
"Lots of Insipid Silly Parenthesis") part is the same, but the
functions that are supported are very different.
In article <····@teddy.UUCP> ···@teddy.UUCP (John P. Nelson) writes:
>> Are lisps
>>REALLY so diverse (disclaimer: I known nothing about lisp except that it
>>is written using Lots of Insipid Silly Parentheses :-) ) that they don't
>>even accept a mutual subset of the language?
>
>Implementations of lisp can have WILDLY different syntax. The
>difference between "Common Lisp" and "Scheme" is huge. The syntax (the
>"Lots of Insipid Silly Parenthesis") part is the same, but the
>functions that are supported are very different.
The essential framework of Lisp: cond, lambda, progn, setq, prog, function
calls, car, cdr, cons, list, atom work pretty much the same in every lisp.
A moderate number of functions (like append) behave the same (at least if
you stick to two arguments, etc).
A further set of functions tend to be sort of similar (e.g. print and read),
but can vary in an amazing number of ways (e.g. does print do new line
before or after printing).
Still other common functions are known under different names:
e.g. nreverse or dreverse for destructive reversal,
put or putprop or (setf(get ... to put on a property list item.
Lisps vary wildly in extensions to lambda (all? do a fixed number of
ordinary arguments in the same way, beyond that, all bets are off), special
forms (like cond -- vary in which are available, whether you can define
more).
The parts of Lisp which you can expect to work the same everywhere is
perhaps a Basic sized subset.
This has happened for several reasons. Before common lisp, there was never
any "official" standard. Also, Lisp is a much easier language to extend
than most because programs are in a data format identical to that which Lisp
was designed to manipulate. As a result, there have been a number of large
groups which have developed major dialects of lisp.
Further, when one lisp group develops an inovative and useful extension to
the language or environment, it frequently gets copied by many of the other
groups (but maybe in slightly different ways because of the differing
environments to which they are introduced).
[I have been involved in several translations between various lisp dialects,
so am familiar with the range of differing similarities. Generally, about
5% of the "features" actually used present real translation problems caused
by radically different solutions to language features.]
--
Darrel J. Van Buer, PhD; unisys; 2525 Colorado Ave; Santa Monica, CA 90406
(213)829-7511 x5449 KI6VY ······@CAM.UNISYS.COM or
...{allegra,burdvax,cbosgd,hplabs,ihnp4,sdcsvax}!sdcrdcf!darrelj
In article <····@sdcrdcf.UUCP>, ·······@sdcrdcf.UUCP (Darrel VanBuer) writes:
> The essential framework of Lisp: cond, lambda, progn, setq, prog, function
> calls, car, cdr, cons, list, atom work pretty much the same in every lisp.
despite set vs. cset, function vs. variable binding (see theological dispute
on net.lang.lisp a few years ago)
> Still other common functions are known under different names:
set! reverse!
> Lisps vary wildly in extensions to lambda
who was it that had something like pattern matching in the lambda-binding?
i.e. list == (lambda x x), car == (lambda ((a . r)) a) etc.
> The parts of Lisp which you can expect to work the same everywhere is
> perhaps a Basic sized subset.
speaking of languages with dialects! Dartmouth vs. uSoft ("street") Basic.
> This has happened for several reasons. Before common lisp, there was never
> any "official" standard.
despite Utah's proclamation of "Standard", then "Portable Standard" Lisp.
> [I have been involved in several translations between various lisp dialects,
> so am familiar with the range of differing similarities. Generally, about
> 5% of the "features" actually used present real translation problems caused
> by radically different solutions to language features.]
sounds about right for most programs in most languages.
From: Stanley T. Shebs
Subject: Re: lisp (Compatibility with Lisp)
Date:
Message-ID: <173@utah-orion.UUCP>
In article <····@uvacs.CS.VIRGINIA.EDU> ···@uvacs.CS.VIRGINIA.EDU (Alex Colvin) writes:
>> [...] Before common lisp, there was never any "official" standard.
>despite Utah's proclamation of "Standard", then "Portable Standard" Lisp.
Standard Lisp was proposed by Tony Hearn in a 1966 Sigplan Notices. Dunno
if he was at Utah at the time, but in any case, this was only four years
after the appearance of McCarthy's JACM article. The chief motivation for
Standard Lisp was to improve the transportability of the algebra system
Reduce, which is widely used by physicists and others. To quote from "An
Overview of Common Lisp" (1982 Lisp conf proceedings, available from ACM):
"While promulgated as a possible standard, it was on the one hand incompatible
in one way or another with most other dialects, and on the other hand really
too small a subset of LISP for its adoption to have any practical effect.
However, even as a dialect used by only one implementation group, it deserves
the name "Standard" more than any other, as it has been implemented for a wide
variety of processors, and code written within that subset is completely
portable, a remarkable achievement."
(The crack about its being too small is a revealing insight into why Common
Lisp is big - Standard Lisp is about the size of Standard Scheme, though not
as clean.)
Portable Standard Lisp is more accurately named "Portable Implementation
of Standard Lisp", but that's a rather pedantic distinction.
stan shebs
·····@cs.utah.edu
> (was: Compatibility with EBCDIC)
?
In article <····@teddy.UUCP>, ···@teddy.UUCP (John P. Nelson) writes:
> > Are lisps
> >REALLY so diverse (disclaimer: I known nothing about lisp except that it
> >is written using Lots of Insipid Silly Parentheses :-) ) that they don't
> >even accept a mutual subset of the language?
This is the usual reaction of non-LISP programmers. I've used half a
dozen dialects, none of which have the same syntax for defining
functions. And that's the main effect of a LISP program!
Syntax is one of the principal concerns of e.g., Basic, Pascal, C, PL1,
Ada. That's what most programmers spend most time on.
In LISP, however, we don't care about syntax. If we don't like it, we
rewire it. We're more interested in semantics. This where the
differences among LISPs become interesting. We sometimes rewire the
evaluator and builtin functions when we don't like the way they work.
Dynamic binding and interpretation make this easy. Especially by
accident.
In article <····@uvacs.CS.VIRGINIA.EDU> ···@uvacs.CS.VIRGINIA.EDU (Alex Colvin) writes:
>In LISP, however, we don't care about syntax. If we don't like it, we
>rewire it. We're more interested in semantics. This where the
>differences among LISPs become interesting. We sometimes rewire the
>evaluator and builtin functions when we don't like the way they work.
This reminds me of the fellow who invented new words as he felt
necessary to express his meaning at the time. He was extremely
happy with himself, and relished his freedom of language. The
only difficulty, of course, was that no one understood what he
was saying.
Steve
***
Thou art beside thyself. Much learning hath made thee mad.
-- Festus (the one in Acts, not Dodge City!)
In article <·····@clyde.ATT.COM> ···@moss.UUCP (Steve Frysinger) writes:
>In article <····@uvacs.CS.VIRGINIA.EDU> ···@uvacs.CS.VIRGINIA.EDU
(Alex Colvin) writes:
>>In LISP, however, we don't care about syntax. If we don't like it, we
>>rewire it. We're more interested in semantics. This where the
>>differences among LISPs become interesting. We sometimes rewire the
>>evaluator and builtin functions when we don't like the way they work.
>This reminds me of the fellow who invented new words as he felt
>necessary to express his meaning at the time. He was extremely
>happy with himself, and relished his freedom of language. The
>only difficulty, of course, was that no one understood what he
>was saying.
That was the wrong association. It should have reminded you of the
skilled machinist who uses *very* general-purpose tools which are
quickly and easily customized by means of jigs and hold-downs to a
special-purpose tool ideally matched to the problem at hand.
You might compare the approach taken to software devlopment by one
influential group at B*ll L*bs described by Ralph E. Griswold in the
book *The Macro Implementations of SNOBOL 4*. These highly respected
computer professionals describe exactly the same approach to system
building that you took Alex Colvin to task for.
Bill Henneman
"Failure to understand reality is not realiy's fault"
- Bill Henneman
From: Peter da Silva
Subject: Re: lisp
Date:
Message-ID: <649@sugar.UUCP>
> This is the usual reaction of non-LISP programmers. I've used half a
> dozen dialects, none of which have the same syntax for defining
> functions. And that's the main effect of a LISP program!
Well, I'm not a non-LISP programmer. I'm also not a LISP-programmer. I'm
a programmer who has had occasion to do work in LISP on a few occasions.
Unfortunately, each time I've had to pretty much learn the language from
scratch...
> Syntax is one of the principal concerns of e.g., Basic, Pascal, C, PL1,
> Ada. That's what most programmers spend most time on.
In LISP, too. Unless, of course, you never use but one LISP. Or maybe you
carry around a bunch of standard functions the way Emacs types carry around
a set of standard macros. The first time you sit in front of the machine
you port your functions to it and forget how the underlying language works.
For people who aren't going to be making a career out of LISP or Emacs, it's
a bit disturbing to be told that we're going to have to sit down and figure
out a set of functions so we can operate in other environments.
> In LISP, however, we don't care about syntax. If we don't like it, we
> rewire it.
Wouldn't it be easier to rewire if you could just keep your toolkit in
Lisp 1.5, so you could use a new system the day you sit in front of it
instead of a week later? FORTH has a similar capability, but if you know
Forth-77 and Forth-83 you can be up to speed in a new FORTH in an hour or
so.
For god's sake... define some subset language that will be available in
everyone's LISP, and stick to it.
--
-- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter
-- 'U` <-- Public domain wolf.
In article <···@sugar.UUCP> ·····@sugar.UUCP (Peter da Silva) writes:
>[...] Or maybe you
>carry around a bunch of standard functions the way Emacs types carry around
>a set of standard macros. The first time you sit in front of the machine
>you port your functions to it and forget how the underlying language works.
Use Common Lisp - then every function you could ever think of has already been
defined and built in! 1/2 :-) People do carry around functions, but this
is less common than it used to be - almost any bit of code in Lisp 1.5 will
fail horribly in Scheme or Common Lisp.
>Wouldn't it be easier to rewire if you could just keep your toolkit in
>Lisp 1.5, so you could use a new system the day you sit in front of it
>instead of a week later? FORTH has a similar capability, but if you know
>Forth-77 and Forth-83 you can be up to speed in a new FORTH in an hour or
>so.
Most people haven't tried Lisp 1.5, so they can talk blithely about
programming in it. Forth programmers may be willing to tolerate operating
at a near-machine level, but the difference between Lisp 1.5 and a quality
Lisp environment is about 20-100,000 lines of Lisp code, depending on your
tastes. You could get a hernia trying to carry it around!
>For god's sake... define some subset language that will be available in
>everyone's LISP, and stick to it.
car, cdr, cons, atom, cond, lambda - not much, but it's provably sufficient.
Now try to program in it!
The usage of the term "Lisp" is rather misleading, since "Lisp" designates a
family of languages rather than a single one. Lisp 1.5, Scheme, Common Lisp,
and 3-Lisp have little in common besides parentheses. Defining a common
subset is about like defining a common subset of C, Pascal, Modula-2, and A*a
(no problem, they all have semicolons, right?).
For Lisp standards, there's Common Lisp and Standard Scheme, but both have
plenty of bashers and haters - some of the commentary I've heard is highly
unprofessional...
>-- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter
stan shebs
·····@cs.utah.edu
From: Barry Margolin
Subject: Re: lisp
Date:
Message-ID: <8229@think.UUCP>
In article <···@sugar.UUCP> ·····@sugar.UUCP (Peter da Silva) writes:
>For god's sake... define some subset language that will be available in
>everyone's LISP, and stick to it.
Well, this is the purpose of the Common Lisp language, although it
will probably not make it into EVERYONE'S Lisp, because it is too big.
However, it looks like most industrial-strength Lisp implementations
are going to be Common Lisp compatible.
---
Barry Margolin
Thinking Machines Corp.
······@think.com
seismo!think!barmar
In article <····@think.UUCP>, ······@think.COM (Barry Margolin) writes:
> In article <···@sugar.UUCP> ·····@sugar.UUCP (Peter da Silva) writes:
> >For god's sake... define some subset language that will be available in
^^^^^^
> >everyone's LISP, and stick to it.
>
> Well, this is the purpose of the Common Lisp language, although it
> will probably not make it into EVERYONE'S Lisp, because it is too big.
If it's too big, it sure ain't a subset.
How about Lisp 1.5? It shouldn't be too hard to at least emulate 1.5, and it
is certainly not too big. I may be biased because I cut my lisp teeth on
1.5, but at that time all the lisp books I could find at least covered it.
--
-- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter
-- 'U` ^^^^^^^^^^^^^^ Not seismo!soma (blush)