levy@ttrdc.UUCP (Daniel R. Levy) (08/26/87)
In article <8452@utzoo.UUCP>, henry@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--------|
ken@argus.UUCP (Kenneth Ng) (08/28/87)
In article <1880@ttrdc.UUCP>, levy@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 ken@bellcore.uucp *** bitnet(prefered) ken@orion.bitnet
jpn@teddy.UUCP (John P. Nelson) (08/28/87)
> 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.
mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (08/29/87)
[Followups have been pointed to comp.lang.misc.]
In article <1022@argus.UUCP> ken@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. mwm@berkeley.edu
His mother sent newspaper clippings to him, ucbvax!mwm
About his old friends who'd stopped being boys. mwm@ucbjade.BITNET
darrelj@sdcrdcf.UUCP (Darrel VanBuer) (08/29/87)
In article <4307@teddy.UUCP> jpn@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 darrel@CAM.UNISYS.COM or ...{allegra,burdvax,cbosgd,hplabs,ihnp4,sdcsvax}!sdcrdcf!darrelj
bc@apple.UUCP (bill coderre) (08/30/87)
In article <1022@argus.UUCP>, ken@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
mac@uvacs.UUCP (09/01/87)
> (was: Compatibility with EBCDIC) ? In article <4307@teddy.UUCP>, jpn@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.
spf@moss.ATT.COM (09/03/87)
In article <1931@uvacs.CS.VIRGINIA.EDU> mac@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!)
peter@sugar.UUCP (Peter da Silva) (09/05/87)
> 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.
barmar@think.COM (Barry Margolin) (09/10/87)
In article <649@sugar.UUCP> peter@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. barmar@think.com seismo!think!barmar
peter@sugar.UUCP (09/12/87)
In article <8229@think.UUCP>, barmar@think.COM (Barry Margolin) writes: > In article <649@sugar.UUCP> peter@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)