|
|
|
|
|
by lispm
4901 days ago
|
|
The undefined behavior in the Common Lisp specification was a design choice. It has nothing to do with 'good' or 'bad' documentation. Common Lisp was designed from 1981 on. The Lisp community (here the successors of Maclisp) went to explore a lot of new ground: implementations on mini computers, mainframes, super computers, parallel machines, microprocessors, stack architectures, on top of other programming languages like C, etc. There were small and stupid compilers, optimizing compilers, whole-program compilers, ... It was a time of experimentation. At that time a lot of behavior was not defined to allow compiler writes to explorer different types of implementations. With the knowledge of a decade later some of that could have been defined more precisely, but then the standardization process ran out of steam due to lack of funding and interest. Using SETQ on an undefined variable may be undefined in the Common Lisp standard, but every implementation deals with that and allows it. That's a non-issue. There are a lot of other things which isn't defined in the standard and which all implementations deal with. Garbage Collection. Also not in the standard, but every user expects garbge to be collected. It would be nice to have less undefined behavior, but it has nothing to do with good or bad. It was useful in a time of experimenting. Even worse for Common Lisp was that in 1981 there wasn't yet an OOP system for Lisp that was explored and accepted. This way CLtL1 was defined without an object system and it had later to be added (CLOS). |
|