Subject: Re: type safety in LISP
From: Erik Naggum <>
Date: 07 Dec 2002 23:05:18 +0000
Newsgroups: comp.lang.lisp
Message-ID: <>

* "marcel haesok" <>
| 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.