Subject: Re: type safety in LISP From: Erik Naggum <erik@naggum.no> Date: 07 Dec 2002 23:05:18 +0000 Newsgroups: comp.lang.lisp Message-ID: <3248291118131892@naggum.no> * "marcel haesok" <novuriche@attbi.com> | I was reading C# book by Jeffery Richter. Quote: "Delegates ensure that | the callback method is type-safe (in keeping with one of the most | important goals of the DOTNET Framework)" This is a peculiar case of post hoc, ergo propter hoc argumentation. It is not type-safe /because/ of the delegates. The delegates have been designed this way because the language implements type-safety that way. | which seems to suggest that "type-safety" is a big issue in real | programming world. It is. But just like the most dangerous man in the world has decided to scare almost 300 million people out of their wits in the name of national security and safety, stripping them of freedoms and rights at a pace that rivals the enemy back when another president defined the four freedoms in response to not dissimilar threats 60 years earlier, the concept of "type- safety" can also be thought of in terms of the freedoms you give up, or in terms of the differences in implementation. Where one president promises his people freedom of speech and freedom from fear in response to threats (very much like Lisp offers freedom of expression when solving the problem of type safety in response to dangerous program errors), another clamps down on the freedom of expression and severely limits what the population may say and offers them fear in response to threats (very much like C++ is extremely restricting and has its users live in perennial fear of abuse of the necessary type-casting operators). It should be obvious from the above that it is not the threat itself that defines the response, but the "personality" of the language (president). The idiot will cave in to the fear and cannot see other solutions than to abridge the freedoms of those he obviously believes he provides "safety" in so doing. The intelligent will transcend the fear and determine the most pacifying strategy, the one showing the most strength and power and understanding of the threat involved, and then take advantage of it. | Lisp, on the other hand, from the readings I've done here, seems noted | for its "dynamism" of type. IE, "type-versatility" of some sort....... It is in fact your understanding of "type safety" that is so limited that you are not even aware of it. Please consider a brief study of logic so you avoid committing so many annoying fallacies. Some languages are "statically typed", which means that the /compiler/ is the last element of the entire production line from programmer to system execution of the binary that knows the type of anything -- the execution environment deals only with bits that have no type at all. (Recall that a bit is a bit is a bit (not unlike a rose), but what it means depends on what the observer wants it to mean.) If you want type safety in a system where the compiler is the last to know, you must ensure that the compiler does indeed know, which is an incredibly complex task. Some languages are therefore "dynamically typed", which means that the type information /does not evaporate/ during processing. Think of compilation as cooking. Dynamic typing means the steak is juicy and still a little red, like red meat is supposed to be. Static typing means you burnt it to a crisp. Dynamic typing means that the /object/ carries the type information. Static typing means that storage container carries it and the object inside it has lost its type information. Some people, when they look at dynamically typed languages from the statically typed language vantage point, seem to believe that since the storage containers are no longer marked and the compiler cannot ensure that only the appropriate kinds of objects are put into them, all hell must break loose. This despite the glaring fact that "object-oriented" programming in these languages introduce some measure of run-time type information. I have a hard time actually imagining what went wrong with people who think this way. It is so short-sighted, so devoid of any thinking skills, so utterly /absent/ of intelligence, that one can only marvel at the ability of the human species to produce this kind of people and yet not destroy itself. Just because you do not know does not mean that you can draw any form of useful conclusions about that which you do not know. I wonder why this is not drilled into the heads of people in kindergarten. In a dynamically typed language, the storage containers are much more generic than the storage containers in the statically typed languages. You do not have to re-introduce the type information to the compiler when you pick an item out of a collection in a properly designed language! The object already carries type information around with it. Storage containers in Lisp can hold objects of any type. The notion that a container for type T1 can hold an object of type T2 is pretty fundamental to the "object-oriented" crowd, yet when it comes to actually implementing it fully, they acquire an amazing array of delusions about efficiency which they either ignored or did not even consider when they were talking their heads off about the amazing power of object-orientation, possibly because their understanding of "object-orientation" is based in "encapsulation" and "inheritance" and /not/ based on type-specific discrimination, which is far more important. For some readers, there is evidently a /qualitative/ difference between addition of numbers of various types and sending "messages" to objects of various genealogy from a common ancestor. It appears to me that the only cause for this rather amazing improvidence is the misguided notion that it cannot be a "class" (or type) unless it stores some data in a container. Thus an /integer/ cannot be a class, functions are not defined on /numbers/ because the "number" is not a structure that contains a virtual function pointer table. Instead of thinking about types and functions on types, the inverse notion that the type owns the function cannot but cause the most heinous malabstraction. | Is LISP type-safe? Suppose I argue that the core purpose of the family is to ensure that the offspring can grow up in safety and comfort and that the core purpose of society is to enable families to provide such measures to their offspring, which is a brief summary of the Republican position. Suppose I wish to /implement/ this by extending the embrace of the familty to the entire popularion and therefore secure the state-supplied safety and comfort through state ownership of all means of production, which is a brief summary of the Communist position. Are Republicans Communists? If the only way you can imagine type safety is through state control and loss of freedom, then you will have to conclude that the implementation thereof does not matter, and since all political schools of thought have been concerned with the physical and extended safety of the population (sometimes through exclusivity as to what constitutes the "population"), there can be no difference between them. If, however, you aim for a much more abstract understanding of "safety" and grasp that it can be taken care of at a different level than controlling all people (or objects), by letting individual people (objects) remain free to be what they want, the world suddenly looks very different. In a world where people believe that only control over other people can produce safety, you get a suspicious lot who are far from safe, but instead fear those they cannot control (as happened in other countries that tried GWB's censorship and surveillance methods). In a world where people trust that those who violate contracts (both social and legal) can be punished and damages repaid, the need for individual suspicion and fear has no place. Just as the right to bear arms was a necessity at a time when the police could scarcely care less (even if they had had the resources) and the gun control crowds primarily wanted to disarm the lower classes for fear of armed uprising, institution of a /working/ police force that the population actually trusts to protect them obviates the need for personal armories, a programming language that provides /no/ safety infrastructure, body (core) dumps in response to any violation, and a direct threat to anyone who carelessly trusts a stranger, /should/ have been obsoleted by a language that offers an infrastructure that maintains security and trustworthiness. Static typing in programming languages is closely akin to the need to bear arms and the purported need to do all this anal compile-time checking is precisely to keep the lower classes in check, the uneducated hoodlums who program for food and wipe your windshield for cash and whose code more likely than not will do something you would rather it refrain from. Dynamic typing in programming languages means you can trust even code that you would not in the static typing world, because it is so much harder to lie successfully. In the static typing world, you need someone else (the compiler) to tell you that the code you talk to is OK before you can trust the /data/ it gives you, and some of the most insidious backstabbers you can think of imagine some draconian measure like "Palladium" because they are unable to escape the confines of their mental models, which produced the virus vehicles they think they can halt by running them off the road, and it all goes downhill from there. The moral of this story that I want you to take with you is that there are more /times/ to get type safety than compile-time. It is in fact a /lot/ easier to get true type safety if you do /not/ do it at compile-time, but people who are massively inept at programming think that if they can catch some bugs at compile-time, that somehow makes all the remaining bugs less important and hard to catch. This is in fact wrong. Empirically, people who believe their compilers will catch bugs for them because it enforces a ridiculously irrelevant aspect of the task of programming, produce /more/ bugs than people who do their testing right and do not believe in a class society for bugs (such that they can ignore or repress some bugs). -- Erik Naggum, Oslo, Norway Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.