[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
nested function definitions interfering with extensibility.
- To: LISP-FORUM at MIT-AI
- Subject: nested function definitions interfering with extensibility.
- From: Richard M. Stallman <RMS at MIT-AI>
- Date: Fri ,19 Jun 81 00:44:00 EDT
Date: 18 June 1981 10:37-EDT
From: George J. Carrette <GJC at MIT-MC>
This certainly true in the case of program editing in a
non-structured text-oriented way, but in a system with
more cooperation between program editor and compiler this
need not be the case. I'm all for editing programs as text,
but I don't like representing them, storing them, as
a sequence of characters, i.e. in a purely syntactic manner.
Why? Because it severely limits program management to
purely syntactical levels.
The problem is not in editing at all. It is easy in any sort of
editor to edit the internal function definition and make no change to
the external one, and vice versa.
The problem comes when you try to store a file which, when loaded,
changes one but not the other. No editing is involved, just loading
of source or compiled files.
IRT Moon's suggestion:
Function specs like (:INTERNAL FOO BAR) for BAR within FOO make it
possible to redefine the internal function without changing the
external one. This is a good solution for that half of the problem.
But how do you redefine the external one without changing the internal