Newsgroups: comp.lang.lisp,comp.lang.icon,comp.apps.spreadsheets
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!fas-news.harvard.edu!newspump.wustl.edu!news.ecn.bgu.edu!vixen.cso.uiuc.edu!news.uoregon.edu!usenet.eel.ufl.edu!news.mathworks.com!news.kei.com!world!NewsWatcher!user
From: rpk@world.std.com (Robert P. Krajewski)
Subject: Spreadsheets and Lisp {was: Letter From Ted Nelson}
Message-ID: <rpk-1006950123280001@192.0.2.1>
Sender: news@world.std.com (Mr Usenet Himself)
Nntp-Posting-Host: world.std.com
Organization: The World @ Software Tool & Die
References: <3r29km$m7p@crl11.crl.com> <D9t2v3.Fty@world.std.com> <3r4kpr$q9q@crl4.crl.com> <hbaker-0706951720170001@192.0.2.1> <3r7jqd$ihb@crl7.crl.com>
Distribution: inet
Date: Sat, 10 Jun 1995 05:23:28 GMT
Lines: 119
Xref: glinda.oz.cs.cmu.edu comp.lang.lisp:18085 comp.lang.icon:3155 comp.apps.spreadsheets:9449

[Most groups removed, comp.apps.spreadsheets added.]

dbennett@crl.com (Andrea Chen) wrote:
>hbaker@netcom.com (Henry Baker) writes:
>
>>In article <3r4kpr$q9q@crl4.crl.com>, dbennett@crl.com (Andrea Chen) wrote:
>
>>> A historical example is the spreadsheet
>>> (a product which helped launch the PC revolution).  Two features
>>> which distinguished it were its matrix frontend and "automatic
>>> recalculation" in the backend.  This second feature is natural to
>>> Lisp dialects which could have served as an engine.  They would
>>> also have provided call by name (not just cell number) and 
>>> "multidimensional" structures.  It took spreadsheet engines over
>>> ten years to evolve these features on their own.

As somebody who has done both Lisp language implementation (Lisp Machine
Lisp, Golden Common Lisp) and spreadsheet implementation (Lotus Improv),
I do not quite follow the implication here, which seems to be that Lisp
has an evaluation model which eases the implementation of a spreadsheet.
Spreadsheet recalculation can be looked as a propagation of changes across
a graph (possibly cyclic), something for a truth maintenance system to
handle in a general way, or an interesting constraint propagation problem,
and those are the kinds of computing applications and strategies that have
been explored quite fruitfully in Lisp (for good reason). But Lisp itself
doesn't really work like spreadsheet. Setting a Lisp variable doesn't make
things happen the way that editing a spreadsheet cell makes things happen.

>>The first spreadsheet _was_ prototyped in Multics Lisp by Bob Frankston,
>>which became 'VisiCalc', I believe.

Most likely, Frankston used Lisp to start prototyping things because he
thought it was a great language for prototyping. Make a mistake, and
you don't kill your environment. In fact, the Lisp in GNU Emacs was used
to analyze some aspects of Improv cell storage. No special reason -- it
was just the most reasonable interpreter we had lying around at the time.
The developer could have used C++ or awk or perl but he had better things
to do with his time.

>Then the author missed some of the funamental powers of Lisp.  One of
>the problems with classical spreadsheet "recalculation" was that
>if a number was changed, the whole thing had to be recalculated.
>As spreadsheets grew more and more powerful computers were requied
>to process in real time.

First, see first paragraph. Second, there are ways to be clever
about the work that has to be done -- it's called "minimal recalc."
Modern spreadsheet data structures usually incorporate some form
of dependency information (which is cheaply pre-arranged) to help
this implementation of this cleverness. In fact, there are situations
where it's faster to just do the evaluation than to figure out if
it should be done in the first place. (Spreadsheets have this luxury
because most operators in the spreadsheet "language" tend to be free
of side effects.)
 
>
>
>In a Lisp statement of the form
>
>(SET CELL1 '(ADD CELL2 CELL3 CELL4))
>
>a change in CELL3 would be automatically compensated for by the statement
>
>(EVAL CELL1)

Sorry, but that doesn't make things any more efficient. Think: who's
going to arrange for (EVAL CELL1), or really, something more like
(SET 'CELL1 (EVAL (GET 'CELL1) 'FORMULA))) to be evaluated in the
first place. Clearly, if you just do that pattern of evaluation for
every cell in the spreadsheet, you're right back to the most
sledgehammeroid spreadsheet implementation possible.

>
>Lisp would also have made it possible to support sparse matrixes thus
>multiplying the amount of data which could be stored.

Although Lisp is a great language for making interesting data structures,
Lisp has no monopoly on a reasonable implementation of sparse matrices.
As it turns out, a commercial spreadsheet usually does have simple
sparse matrix implementation -- for a two-dimensional spreadsheet, simple
is usually good enough for real-world cases. In fact, that GNU Emacs
Lisp-using developer I mentioned earlier did a very clever C++-based
implementation of a matrix of cells (Improv worksheets can have up to
twelve dimensions) that handled sparseness quite nicely, thank you.

>It would also
>be possible to make symbolic links to the grid form (which helps make
>the frontend (interface) easy to use.
>
>(SET FIRST_QUARTER CELL1)
>(SET JAN CELL2)

Cool, but why bother with cell names in the first place ? If you can
scare up a copy of Improv (development after version 2.1 for Windows
was cancelled approximately a year ago), you'll see what I mean. But
you're right in noticing the connection of this feature with Lisp.
Improv's name-to-internal-location mapping implementation is much like
what Lisp hackers used to call an "obarray", on which strings are "interned,"
yielding "symbols." (It is run on exactly the same principles: hashing
text, and maintaining one unique object for each text string encountered.)

>And also to build non numeric logics into the system. ics
>inherant in Lisp (or Snobol or a number of other languages) could
>have provided a far richer logical environment for spreadsheets.
>Only in the last five years have these evolved independantly into
>modern spreadsheets.

True, although I think strings have been there since the beginning.
A sad example: in the three spreadsheets I know best (Excel, 1-2-3,
Improv), a date is just a number *formatted* in a certain way. And,
I beleive that early versions of the Mac and Windows version of
Excel used slightly different conventions for the representation of
a date as a number (I think the difference was which date was "0.")
Ugh !

Improv did advance the model of a spreadsheet, but the real
leap that nobody's really made yet is to allow arbitrary datatypes
to participate in what a spreadsheet is good at -- taking a set
of rules and values, and keeping them consistent.
