From: Jeff Dalton
Subject: Re: CL standardization (identifiers'semantics and symbols)
Date:
Message-ID: <6263@skye.ed.ac.uk>
In article <······················@waxwing.parc.xerox.com> ········@waxwing.parc.xerox.com (Vincent Delacour) writes:
>
>Some people have tried to show (to me?) in previous messages that it
>is indeed possible to build programs with defpackage, and that
>computations with package operations are deterministic. What a relief!
Not just deterministic. The mapping from names to symbols can be
analyzed statically -- if you follow certain concentions in how
you use Common Lisp.
>This need not be answered because it is obvious. Sure, yes, indeed,
>(etc). However, the authors of these messages seem to miss a few
>points in CL's semantics:
Actually, they do not miss any of these points (where the points
are correct).
>First: programs and identifiers
>-------------------------------
>
>CL's identifier's semantics are heap-based because changes in the
>package system state are permanent (until the world is restarted ;-),
>so you can never tell for sure what a name occurence, such as foo:bar
>(or simply foo) in a variable position, means --- unless you have a
>record of all package manipulations performed so far.
That's why you should restrict what package manipulations you do.
The difference between Common Lisp and the languages you like
is that Common Lisp lets you change the mapping from names to
symbols and those other languages do not. But implementations
of those other languages could provide ways to change the mapping,
perhaps as part of the "programming environment".
Common Lisp, and Lisp generally, draws the line between language
and environment at a different point than other languages. But
if you shift the Common Lisp line to match the other languages,
they are not so different as you suppose.
For instance, remove LOAD, COMPILE-FILE, and all package operations
except IN-PACKAGE and DEFPACKAGE; and require that programmers compile
Lisp programs by typing a shell command that lists all the files:
lisp file1 file2 file3 ...
Sure, READ would still add new symbols to packages, but nothing
would change the mapping from names to symbols.
In effect, what you want is for Lisp programmers to be forced to
use their language this way. And then implementations that wanted
a flexible programming environment would have to add those features
in a separate, non-standard way inaccessible to programs. Is that
really supposed to be better?
>Indeed, in most programming languages, the semantics of programs are
>statically deducible from the their texts. For those who are familiar
>with modular languages, just think of programs written in one of these
>languages, and using a "symbolic computation" module or library
>(offering read, intern, etc) to perform symbolic computations. Just
>see that:
>
> . the modular structure of the program has nothing to do with
> the use of symbols as data;
Imagine instead a "code analysis" package that analyzed source
code. Call the data structures that represent global identifiers
in the source code "symbols".
Rather than keep symbolic computation and source code analysis
separate, Lisp uses symbolic computation to analyze source code.
What's so bad about that?
>The very peculiar semantics of identifiers in CL make directly or
>indirectly most of the language's complexity.
That is not so.
>They forced the language designers to introduce special-purpose
>constructs (such as eval-when) to deal at a source level with
>the implications on the compilation-time load-time and execution
>time of the entanglement of heap-living structures, and identifiers
>semantics.
Some Lisps don't have EVAL-WHEN, and it could be removed from Common
Lisp even though packages remained. Moreover, EVAL-WHEN predated
packages. So it is simply false that the "peculiar semantics of
identifiers" forced the language designers to introduce EVAL-WHEN.
>Second: symbols
>---------------
>
>As pointed out by somebody, " Identifiers are names, symbols are
>objects" (and these are different notions).
So they're different. So what? That doesn't mean names can't
be a kind of object, or be represented by objects. Symbols are
just the objects that represent names.
Or do you want to say compilers shouldn't exist, because identifiers
are names, and the compiler's data structures are objects (and these
are different notions)?
If anything, the reflective aspects of Lisp should be increased
(by metaobject protocols, for example) rather than decreased.
>Some seem to advocate that programs that manipulate symbols should not
>perform package operations other than (at most) creating packages and
>interning symbols. The underlying assumption is that complex
>operations on the package's state (such as importations, shadowings,
>etc) belong to the modules world.
Lisp can be used in different ways. If you want some packages to be
like modules, you can restrict your use of those packages. When
someone seems to be arguing that all packages should be like modules,
it's reasonable for other people to point out that they can be.
However, other packages can be treated differently. For instance,
if I write another language in Lisp, my compiler or interpreter
may use packages for certain aspects of programs in that language;
and those packages will be treated as data structures.
>Indeed, but in current Common Lisp,
>any interned symbol (and interned symbols may be convenient ;-)
>belongs (in some way) to a package. So when you manipulate symbols,
>(for example if you read some data) you are very likely to affect the
>packages/symbols state as well. Unfortunately, even _creating_ a
>symbol may break a program (for ex: it will not compile anymore), and
>may require either some package surgery, or restarting Lisp.
Not if you follow the suggestions made earlier (eg, by Bob Kerns).
>IMO the most inconvenient side of the current package/symbols system
>is that programs that manipulate symbols see things that do not belong
>to the execution. For example, changing the modular structure of a
>program can affect its runtime behaviour.
Again you're asking us to separate language and environment
at the point other languages do rather than at the point Lisp does.
Evidently you think there's only one good way to do this, and Lisp
isn't it. I disagree. There's more than one good way.
>Programming with symbols would be made much simpler if identifiers
>were given static semantics, not related to the symbols system state.
>I didn't see any argument in the answers I got that justify in any way
>the current entanglement of symbols, package, and module-related
>constructions.
That's because you're not trying.
Lisp allows Lisp programs to do things that other languages place
out of their reach in, say, the debugger, or at an environment level
accessible to the user but not to programs. Lisp makes many of
these things accessible to programs. Programs don't have to use
those features, but they can.
By making those features available, Lisp makes it easy to implement
languages in Lisp and to provide Lisp programming tools in Lisp.
The alternative is to make such things harder, if not impossible,
Consider TRACE as a simple example. TRACE can be written in Lisp
because it's possible to call SYMBOL-FUNCTION and to do SETF of
SYMBOL-FUNCTION. And that's possible because function names
(identifiers) are objects (symbols) that can be passed to
SYMBOL-FUNCTION. If identifiers could not be objects, which
seems to be part of what you want, TRACE would be impossible.
>In conclusion, I can only but repeat that the current semantics of
>symbols and identifiers in Common Lisp are unsafe, and constitute a
>serious drawback of the language; these current semantics
>comes only from previous implementation techniques. They could be
>fixed without affecting the taste of the language, to the great
>benefit of both.
You'd really need to say something more to substantiate this claim
that they come only from previous implementation techniques or that
they could be "fixed" without affecting the taste of the language.
-- jd
From: Jeff Dalton
Subject: Re: CL standardization (identifiers'semantics and symbols)
Date:
Message-ID: <6273@skye.ed.ac.uk>
I think some of Vincent Delacour's points make a certain amount of
sense. Both Scheme and EuLisp will have something more like his
"modules" and less like packages. But there are several things
that I think are wrong with the particular argument Vincent is
making.
In Lisp, there is in effect a two-part mapping from names in source
text to values. READ maps names to symbols, using packages; EVAL
maps symbols to values, using environments. There are advantages
to placing "modules" between symbols and values (as a kind of
environment) rather than between names and symbols (as in packages),
even if you don't have first-class modules/environments.
But there are also disadvantages, especially if programs can't
perform operations on modules/environments (because they're not
first class).
One problem with Vincent's argument is that he says there are _no_
disadvantages.
Moreover, several issues are being mingled and confused:
1. Whether the module-like mapping should be between names (source
text) and identifiers or between identifiers and values.
2. Whether it should be possible to operate at run-time on
the mapping provided by packages or first-class environments.
3. Whether identifiers should be represented as symbols.
Finally, many of his arguments against being able to change
the interpretation of names could also be used against macros
and reader macros. After all, macros are written in Lisp,
and so their expansion depends on the current run-time state
of the system.
-- jd
I'd go in another direction about Delacour's argument. The language
has been extended to provide modules in an important way: CLOS. A
Class is capable of providing perfectly disjoint safe namespaces with
private access to instance and class variables. You can easily make
the argument that this is one of the best features of an object
system.
But I think that Jeff Dalton is right, if we want a static language
there are many from which to choose, C, Pascal, Algol, Fortran all meet
his objections of not allowing the environment to be mutable, and
without such flexibility, LISP is just another language.
--
Douglas S. Rand
Internet: <······@mitre.org>
Snail: MITRE, Burlington Road, Bedford, MA
Disclaimer: MITRE might agree with me - then again...
Amateur Radio: KC1KJ