[comp.lang.c] lisp

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)