rh@smds.UUCP (Richard Harter) (06/29/91)
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.
gateley@rice.edu (John Gateley) (06/30/91)
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