jack@citcom.UUCP (Jack Waugh) (07/11/87)
Is it possible to solve serious programming applications with LISP without using replacement operators? To put it another way, could a list be implemented in any other way than as a chain of cons nodes? This is a novice type question, so please don't reply publicly.
gaynor@topaz.rutgers.edu (Silver) (07/13/87)
> Is it possible to solve serious programming applications with LISP > without using replacement operators? To put it another way, could a > list be implemented in any other way than as a chain of cons nodes? > This is a novice type question, so please don't reply publicly. Not nearly so novice as you think. Any thoughts on alternative structures/paradigms? name: Andy Gaynor (Silver) uucp: {ames, cbosgd, harvard, moss, seismo}!rutgers!topaz.rutgers.edu!gaynor arpa: gaynor@topaz.rutgers.edu icbm: 40 34 N / 74 45 W
bart@reed.UUCP (Bart Massey) (07/13/87)
In article <13278@topaz.rutgers.edu> gaynor@topaz.rutgers.edu (Silver) writes: > > Is it possible to solve serious programming applications with LISP > > without using replacement operators? To put it another way, could a > > list be implemented in any other way than as a chain of cons nodes? > > This is a novice type question, so please don't reply publicly. > > Not nearly so novice as you think. Any thoughts on alternative > structures/paradigms? At Reed college we are currently doing almost all of our lisp programming in an in-house dialect which supports neither destructive list functions nor dotted pairs. The internal form of lists is a lispval car, and a pure-pointer cdr. This greatly increases the efficiency of the language, effectively making the replacement operations and dotted-pair notation unnecessary (all we could ever figure out that they were good for was efficiency anyway, and whatever they gained in efficiency they lost in verifiability and understandability.) We have written several substantial applications in this lisp (e.g. a UNIX shell, an LL(1) parse table generator) and never once missed the features we left behind. In case anyone is interested, the following major changes in the language were also implemented, and have proven useful: - Elimination of eq: Using a properly written version of equal, eq is the first thing to happen anyhow, and we've never encountered a situation where knowing that two lists were non-eq is "good enough". - Functions as first class lispvals: We eliminated the seperate "function cell" in favor of scheme-style first class functions. Seems like a big win in every way. - No intrinsic property lists: There's a fairly efficient prop-list emulation package, but we use it mostly for porting outside code, and encourage programmers to avoid prop-lists. It's always trivial, when writing the code, to work around them, and it's yet another extra cell per atom to be avoided, in addition to often making the code more confusing. All of the above-mentioned features have been uniformly good experiences for us. Benefits we expected and received include: - It's really much harder to write twisty, unreadable lisp code, so we can generally read other folks' code easier. - It's much easier to teach the language to novices, as things are much more uniform and the internals are much better hidden. - It's much easier to redesign the internals, as they don't need to affect the externals very much. We will probably distribute this lisp soon. Your comments and suggestions are welcome. Bart Massey UUCP: ..tektronix!reed!bart
neves@ai.WISC.EDU (David M. Neves) (07/19/87)
In article <6601@reed.UUCP> bart@reed.UUCP (Bart Massey) writes: >At Reed college we are currently doing almost all of our lisp >programming in an in-house dialect which supports neither destructive >list functions nor dotted pairs. ... >In case anyone is interested, the following major changes in the >language were also implemented, and have proven useful: > >- Elimination of eq: Using a properly written version of equal, eq is >the first thing to happen anyhow, and we've never encountered a >situation where knowing that two lists were non-eq is "good enough". > I can construct such a situation. Imagine a list of lists. You want to find out if a list you have a pointer to is contained within that list (i.e. MEMBER). You want to use EQ as the comparison function for efficiency -- especially if the first few characters of the non eq lists are the same as the one you are looking for. e.g. look for (a b c) object in List: ( (a b z) (a b a) (a b c d) (a b q) (a b r) (a b c) ) David Neves, Computer Sciences Department, University of Wisconsin-Madison Usenet: {allegra,heurikon,ihnp4,seismo}!uwvax!neves Arpanet: neves@cs.wisc.c.cN