🚀 go-pugleaf

In article <4623@optima.cs.arizona.edu>, gudeman@cs.arizona.edu (David Gudeman) writes:
> In article  <1991Jun26.223026.13792@watserv1.waterloo.edu> Michael Coffin writes:
> ]There's at least one advantage to the lisp syntax, and that advantage
> ]is important to lispers, although others may not find it important.
> ]Lisp programs have a simple, logical representation as data within
> ]lisp: a program is a list of lists, i.e., a tree.

> I'll agree that that would be a huge advantage if it were only
> possible with lisp syntax.  But in prolog you can do anything that you
> can do with lisp syntax, and prolog uses mostly conventional
> function-call and operator syntax.

> And I understand (from reading, not first-hand experience) that there
> are some languages that have even improved on prolog in this area.

I can do this sort of thing in Lakota, e.g.

	set-list prog {procedure fooby}

sets the contents of of list prog to be the statements of procedure fooby,
and 
	execute-string blatifu

interprets the contents of string blatifu as a sequence of statements
which are then executed.  I find these capabilities moderately useful.
Example: I have interactively entered a procedure, used it, and then
decided that I want to modify it so I print the procedure to a file,
edit, and then execute the file to recapture the procedure.  Convenient
but not earth-shaking.  Example:  I have a library which I don't want
to load into memory but which I want available.  I associate with each
entry point in the library a stub with the same name.  The stub executes
the library file, replacing the stub with the real routine, and invokes
the real routine with the arguments passed to the stub.  Again, a
convenience, but only that.

My question is this: People regularly cite the ability to treat programs
as data as an important feature of lisp.  Fine.  What is this ability
good for that makes it so important.  I can see the utility of programs
that write programs that will be executed later.  But it seems like
treating programs as data involves two steps:

	from data X create program (=data) Y
	using data Z as input execute program Y producing W

However the program in the first step logically should be able to take
X and Z an inputs and produce W; an interpretation of X is required
in either case.  The program writing program may be more efficient
since the interpretation is done once.  However that is an engineering
question.  What is the conceptual gain and how does it work in practice?

For example, suppose I am writing a natural language whazis, and I
decide to create a procedure for each word.  That sounds nice.  However
why do I have to create a procedure for the word?  The code that writes
the procedure "knows" all the decisions that go into writing the procedure
for the word.  Or to take another context if I have table driven code
why create procedures for the table entries?

Can someone cite some examples where data=program is essential.
-- 
Richard Harter, Software Maintenance and Development Systems, Inc.
Net address: jjmhome!smds!rh Phone: 508-369-7398 
US Mail: SMDS Inc., PO Box 555, Concord MA 01742
This sentence no verb.  This sentence short.  This signature done.

Richard Harter:
   Can someone cite some examples where data=program is essential.

The canonical examples are:

(1) creation of development tools (e.g. debuggers, optimizers,
archival systems).

(2) symbolic math packages.

I'm not sure if these show that data=program is essential, but then
data and control flow are just two aspects of the same thing.

I think the best argument for a language which can manipulate its own
code is Von Neumann's: you can develop faster if you can use the
machine to manipulate your code.  Another argument is robustness of
data structures: such a language must have an adequate set of data
structure primitives.

Enough said?

-- 
Raul <rockwell@socrates.umd.edu>

In article <610@smds.UUCP> rh@smds.UUCP (Richard Harter) writes:
   Can someone cite some examples where data=program is essential.

In a word: macros.

j
--
"I've thought the thoughts of little children and the thoughts of men
 I've thought the thoughts of stupid people who have never been
 so much in love as they should be and got confused too easily
 to fall in love again." The Residents and Renaldo and the Loaf