We all know the powerful implications of the program-data identity
in LISP. Most of the power comes from one side of the identity,
that is, that programs are data.
What about the other side of the identity, that lists are treated
as programs (by the interpreter)? I'm wondering what advantages
there are to being able to treat any list as a program (i.e. procedure
call).
For example, say we choose a new representation for 'procedure call'
expressions. Suppose we required that they look like (applic op x y),
i.e. a list that must be headed by the 'applic' symbol (which is not
bound to anything, it's just syntactic). In other words, procedure
calls
are special forms, too.
Now, only a finite number of lists actually correspond to programs
(i.e. all our special forms). Lists no longer default to
procedure-call
semantics.
What disadvantages, other than the inconvenience of always having to
cons 'applic' and the list desired to be 'executed' together, are
implied by such a representation?
Concrete examples?
On 3 Mar 2005 04:51:41 -0800, <·······@csd.uwo.ca> wrote:
> We all know the powerful implications of the program-data identity
> in LISP. Most of the power comes from one side of the identity,
> that is, that programs are data.
>
> What about the other side of the identity, that lists are treated
> as programs (by the interpreter)? I'm wondering what advantages
> there are to being able to treat any list as a program (i.e. procedure
> call).
This is the whole point of such programs as lilgp.lisp. Great for
solving tough relational problems.
--
Everyman has three hearts;
one to show the world, one to show friends, and one only he knows.
va1 wrote:
> We all know the powerful implications of the program-data identity
> in LISP. Most of the power comes from one side of the identity,
> that is, that programs are data.
>
> What about the other side of the identity, that lists are treated
> as programs (by the interpreter)? I'm wondering what advantages
> there are to being able to treat any list as a program (i.e. procedure
> call).
A list can only be successfully treated as a function call only if the
environment in which it is interpreted (or compiled, no difference here)
contains a definition for the name with which you refer to a function.
Your requirement to always use 'applic' doesn't change this in a
fundamental way: It is already the case that not all "correct" lists are
also "correct" programs.
Pascal
Yes, I was assuming the environment had bindings for the cars of
the lists in question.
What I mean is, to the interpreter an unquoted list is treated
as a function call if it's not first found to be a special form.
(then, of course if there's no binding for it's car field, we get
an error).
I'm wondering what happens if we take away that default meaning
of an unquoted list: how inconvenienced we'd be (apart from verbosity).
I don't have enough experience with Scheme to know how handy
the default meaning of an unquoted list really is.
For starters, we wouldn't have a recursive definition for the 'applic'
special form. That is, internally an applic structure wouldn't be
represented as nested 'applic's. Meaning function application
expressions always have to be preconceived. That bugs me.
Should it?
>
> Does it bug you that your CD player doesn't play DVDs?
>
Of course not; there's no way of making it do so. But I
can turn any symbol-headed list into a function call just
by defining an appropriate binding.
A. Huerter wrote:
>>Does it bug you that your CD player doesn't play DVDs?
>
> Of course not; there's no way of making it do so. But I
> can turn any symbol-headed list into a function call just
> by defining an appropriate binding.
You can change a CD player into a DVD player by opening it up and
replacing its drive. ;)
Can we agree on not stretching analogies too far? ;-)
Pascal
Pascal Costanza <··@p-cos.net> writes:
> A. Huerter wrote:
> >>Does it bug you that your CD player doesn't play DVDs?
> > Of course not; there's no way of making it do so. But I
> > can turn any symbol-headed list into a function call just
> > by defining an appropriate binding.
>
> You can change a CD player into a DVD player by opening it up and
> replacing its drive. ;)
>
> Can we agree on not stretching analogies too far? ;-)
It's not stretched too far. Hofstadter used it a lot. You can also
open up the source of your program and replace the interpreter for
data of form X by an interpreter for data of form Y.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The mighty hunter
Returns with gifts of plump birds,
Your foot just squashed one.