|
|
|
|
|
by betterunix
4902 days ago
|
|
"I don't think anyone with actual first-hand knowledge of the CL ecosystem would make this comment" I'll make that statement, but only in a somewhat pedantic sense about the language standard itself. Yes, I know CLTL2 is over a thousand pages long, but the one thing about programming languages that always bothers me is undefined behavior. Sadly, even Common Lisp has undefined behavior; Paul Graham's book On Lisp actually relies on undefined behavior being implemented in a particular way e.g. using setq on an unbound variable. Good documentation should not leave anything undefined; good documentation should leave no questions about the semantics of a system/API/language. Given source code and documentation, it should be possible (perhaps difficult, but possible) for a person to figure out what will happen if the program is run. |
|
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).