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.BITNETdarrelj@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.
mac@uvacs.CS.VIRGINIA.EDU (Alex Colvin) (09/03/87)
In article <4776@sdcrdcf.UUCP>, darrelj@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.
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!)
hen@bu-cs.BU.EDU (Bill Henneman) (09/04/87)
In article <13290@clyde.ATT.COM> spf@moss.UUCP (Steve Frysinger) writes: >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. 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
shebs@utah-orion.UUCP (Stanley T. Shebs) (09/04/87)
In article <1937@uvacs.CS.VIRGINIA.EDU> mac@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 shebs@cs.utah.edu
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.
shebs@utah-orion.UUCP (Stanley T. Shebs) (09/08/87)
In article <649@sugar.UUCP> peter@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 shebs@cs.utah.edu
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)
gupta@prlhp1.prl.philips.co.uk (gupta) (03/17/89)
Anyone got any ideas on the following consecutive garbage collections ? 1> (gc) ;;; GC: 700946 words [2803784 bytes] of dynamic storage in use. ;;; 1395954 words [5583816 bytes] of free storage available before a GC. ;;; 3492854 words [13971416 bytes] of free storage available if GC is disabled. 2803784 5583816 13971416 2> (gc) ;;; GC: 700934 words [2803736 bytes] of dynamic storage in use. ;;; 1395966 words [5583864 bytes] of free storage available before a GC. ;;; 3492866 words [13971464 bytes] of free storage available if GC is disabled. 2803736 5583864 13971464 3> (gc) ;;; GC: 700940 words [2803760 bytes] of dynamic storage in use. ;;; 1395960 words [5583840 bytes] of free storage available before a GC. ;;; 3492860 words [13971440 bytes] of free storage available if GC is disabled. 2803760 5583840 13971440 4> (gc) ;;; GC: 700944 words [2803776 bytes] of dynamic storage in use. ;;; 1395956 words [5583824 bytes] of free storage available before a GC. ;;; 3492856 words [13971424 bytes] of free storage available if GC is disabled. 2803776 5583824 13971424 5> (gc) ;;; GC: 700944 words [2803776 bytes] of dynamic storage in use. ;;; 1395956 words [5583824 bytes] of free storage available before a GC. ;;; 3492856 words [13971424 bytes] of free storage available if GC is disabled. 2803776 5583824 13971424 Usually, while I get a cup of coffee, I get Lisp to garbage collect twice. This way, by the time I'm back, its through and I am saved the agony of a g.c. when it doesn't suit me. What I cannot understand in the above printout is why free storage space decreased. There weren't any other process running (this is Lucid Common Lisp 2.10 on an Apollo 3000 with 8MB RAM).
susan@lucid.com (Susan Rosenbaum) (03/22/89)
With regards to the question on why free storage space changes during consecutive toplevel gc's, it is due to the fact that the evaluator variables are being changed. [see CLtL, p. 325] The '+' variables are getting set to be a list of one element (the symbol 'GC); the '*' variables are being set to the 1st value returned by gc (a fixnum); the '/' variables are being set to the list of multiple values returned by gc (a 3-element list). Susan Rosenbaum susan@lucid.com
aps@stl.stc.co.uk (Andrew Sinclair) (05/02/90)
Sorry if you have heard this before (I'm new to the group). I am looking at LISP for modeling purposes. Can anyone recommend a reasonably priced LISP package (Compiler/interpreter, debugger, library etc) to run on a PC. My only prerequisites are that it is Common LISP (or a very good approximation) and that the library contains a reasonable graphics interface. I have looked at IQ/LISP, (the expensive) Lucid LISP, PC Scheme and TransLISP. Thanks in advance Andrew. +----------------------+----------------------------------+-------------------+ | Andrew Sinclair, | Phone: (+44) 0279 29531 ext.2461 Fax: 0279 441551 | | STC Technology Ltd, | Reply-To: aps@stl.stc.co.uk | | London Road, +------------------------------------------------------| | Harlow, |Disclaimer - The views and opinions expressed here may| | Essex CM17 9NA, U.K. |not necessarily be those adopted by STC Technology Ltd| +-----------------------------------------------------------------------------+ +----------------------+----------------------------------+-------------------+ | Andrew Sinclair, | Phone: (+44) 0279 29531 ext.2461 Fax: 0279 441551 | | STC Technology Ltd, | Reply-To: aps@stl.stc.co.uk | | London Road, +------------------------------------------------------| | Harlow, |Disclaimer - The views and opinions expressed here may| | Essex CM17 9NA, U.K. |not necessarily be those adopted by STC Technology Ltd| +-----------------------------------------------------------------------------+
SEB1525@mvs.draper.com (01/10/91)
On 7 Jan 91 18:36:32 GMT "Jonathan H. Young" <young@icad.com> said: >Are there any Mainframe CommonLisp implementations out there? I know >about KCL and VaxLisp; I was hoping for something with better >performance and perhaps commercial support. > >Pointers to an on-line listing would also be welcome. > >Thanks in advance. > > --- Jonathan I don't know if you're referring to an IBM or DEC mainframe, or if you're referring to MVS or VM if it's IBM. However, here's the situation as far as IBM mainframes go. On VM... I think Lucid may have a CL for VM, but I'm not sure. I certainly expect them to be working on it. IBM used to market a product called Lisp/VM (out of the Watson Research Center in Yorktown) which wasn't a Common Lisp, and didn't last long. On MVS... Lucid markets Common Lisp for this platform. It used to be an IBM product (though it was still Lucid's compiler) until a year or so ago when IBM withdrew it due to inability to interest customers. It's a huge product that requires a network of PC's and user licences to operate (the requirement for PC's running Microsoft Windows may be obsolete with V2 of the product). Here at Draper Lab we run an internally developed MVS Lisp (called "Zil") on our IBM ES/9000 (formerly 3090). It's not 100% Common Lisp, but is close enough, and also has some Maclisp features. ZIL features assembler-coded bignums, a compiler that does source transforms, FLAVORS for object-oriented programming, and support for invoking TSO commands and ISPF services from within Lisp. Debugging support is minimal - it has TRACE and it will display the control stack when an error occurs, and that's about it. For an editor, it uses the ISPF editor (if ISPF is available). The Maclisp compatibility was required for DOE-Macsyma, which we ported to MVS from the VAX NIL version. It's arguably the fastest Macsyma running, and has been in full production here for use by our engineers and scientists. (We also have OPS5 running under Zil on MVS.) The garbage collector is a combination of mark-and-sweep and stop-and-copy, and also utilized the 3090 Vector Facility when we had one. The entire system exploits MVS/XA, using memory above the 16-megabyte line. Zil runs in foreground using TSO on plain IBM 3270 terminals, or in batch via JCL. Making Zil available outside of Draper depends on the level of interest (which isn't very high for IBM mainframes). Boston University is one site which has a test copy on their 3090's VPS operating system. I hope this answers your question. - Steve Bacher - Charles Stark Draper Laboratory - Cambridge, MA