which seems to suggest that "type-safety" is a big issue in real programming
world.
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.......

Yes.

(declare (optimize (safety 0) (speed 3)))

No.

Lisp is by smart people, for smart people.  Is C#?

"So given my conclusion, that static typing, as implemented by languages
like C and Pascal, is a failure, what can we do about it? One strategy is to
simply give up and forget about static typing. This strategy has been very
successful. Languages that do this include APL, the perennially popular
Lisp, the Unix scanning language AWK, and of course Perl."

Incidentally, I was surprised by the phrase "the PERENNIALLY popular Lisp".

So its seems that LISP is not the 'ELITE LANGUAGE' that many here
newsgroupers seem to believe, but a very POPULAR language.

Could be that's just the folks I hang around with. They think Lisp is great
but they might still say "You used Lisp for that?" if they thought some
lighter weight language was more appropriate to the problem.

  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.

"In the end, I have to say that the type checking was more help than
hindrance, especially in the construction of the continuations building
block. I had the same experience with Haskell that I had twenty years
ago with ECL [...] (which was, in effect, also a strongly-typed dialect
of Lisp): almost always, once I made the type checker happy, the program
was correct." (in "Building Interpreters by Composing Monads", POPL'94)

 >   Empirically, people

Pascal

Pascal

--
Raymond Wiker                        Mail:  Raymond.Wi...@fast.no
Senior Software Engineer             Web:   http://www.fast.no/
Fast Search & Transfer ASA           Phone: +47 23 01 11 60
P.O. Box 1677 Vika                   Fax:   +47 35 54 87 99
NO-0120 Oslo, NORWAY                 Mob:   +47 48 01 11 60

Haskell is dynamically typed, is it not? Which basically means that
the above is not a counter example...

Pascal

P.S.: Thanks for the other comments - nothing to add.

Does this help?

Pascal

If you can't prove to the compiler that your case statement covers *all*
the possibilities then you have to add a default branch that does
something appropriate.  Such as throw an exception.

Static typing people tell me that this is somehow different from the
compiler automatically inserting the exact same runtime check and
exception in dynamically-typed languages such as Dylan or Lisp or
Smalltalk.

  A counter-example is an example of something quite different than
  what has been claimed, intending to refute the claims.  However, I
  made no claims about Haskell, nor any claims to universality that
  can be shot down with a simple counter-example.  I do know enough
  about logic to avoid that kind of stupid traps, and so should you.

  You have shown an /additional/ piece of information, namely that
  static typing can be done better than the languages that were under
  discussion in this case.  Someone who reads about C# and asks some
  questions about type-safety is unlikely to have the prerequisites to
  understand what Haskell is, as well as being completely unable to
  enter a context where it makes sense to talk about that language.

--
Erik Naggum, Oslo, Norway

[...]
 > 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.

Then I have quoted the following statement by Guy Steele: "[...] almost
always, once I made the type checker happy, the program was correct."

These two statements contradict each other. There are only few kinds of
differences that are stronger than contradiction. The situation Guy
Steele describes _is_ a counter example.

Pascal

  Really?  There is no controversy over type safety that I know of.
  There is great controversy over how to implement it, however.  This
  is not unlike the political scene, where /nobody/ argues that each
  individual should be left entirely alone to fend for himself.  The
  many different ways political groups argue for the implementation
  of safety measures and carefully balancing them against freedoms
  and human rights should not be interpreted to mean that those who
  do not agree with any particular measures to implement safety and
  social and national security are fighting against safety and social
  and national security.  You would have to be astonishingly ignorant
  of history, human nature, and politics to believe that core human
  needs are controversial because their means of implementation is.
  So, too, with type safety in programming languages.  /Nobody/ wants
  programming languages that only ship bits around.  /Everybody/ is
  in full agreement with everybody else that even though processors
  ship machine words around in general-purpose registers and memory
  cells that can hold any machine word, it is considered imprudent to
  design programming languages that do not retain type information in
  some form and ensure that a machine word that represents a value of
  one type is not confused with another.  Controversial this is not.

| There are many very smart people who think it sucks.

  Can you name one person who thinks type safety sucks who is not
  also a complete moron with zero understanding of what it means?

  If /you/ confuse type safety with explicit, static typing, that is
  your problem and you should upgrade yourself forthwith.  Please do
  not repeat your conflated misunderstanding.

--
Erik Naggum, Oslo, Norway

  Wrong.  /Think/, now.  How can I flatly reject your claims, which
  you only repeat with that stubborn "I'm right, so there" attitude?
  Could it be that you bring to your reading of what other people
  write so much baggage that what other people write is immaterial
  for your conclusions?

| I don't think so.

  You have never thought long enough to realize the value of context,
  so why should you start now?

  Think, even though it hurts.  You may actually learn something new,
  and it may tear down several of your personal beliefs.  One of the
  most obvious ones is that you appear to believe that knowledge of
  the truth does not need to be acquired through mental effort, but
  that it is sufficient for something to just "be true".  Another is
  that you appear to believe that when you read something, only you
  have the proper understanding of what it means and that the author
  in particular has lost the right to tell you that it looks like you
  have misunderstood.  Both have in common that you appear to believe
  that your interpretation of something is "the truth", infallibly.
  To be blunt, I find this aspect of your behavior extremely annoying.

--
Erik Naggum, Oslo, Norway

I consider it a fundamental mistake to use a general term for a proper
subset without saying so. I didn't expect you to be more liberal in that
regard.

Pascal

[1] This would also explain your statement about me having "shown an
/additional/ piece of information".

# 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.  (Erik)

# almost always, once I made the type checker happy, the program
# was correct.  (Guy Steele)

These two statements do indeed /not/ contradict each other.  Why
do you think they do?

Regards,
--
Nils Gösche
Ask not for whom the <CONTROL-G> tolls.

"people who are massively inept .." means "only people who are massively
inept"

Pascal does not believe Guy Steele was massively inept at programming

The bugs in a set of bugs which is "almost always" empty are both less
important and easier to catch than the bugs in a set which contains "some
bugs."

Our ability to form quite sane abstractions that thwart even the
fanciest static type checkers exceeds the ability of static type
checker generators to keep up.  

Well, duh ... that's just an instance of the "All we have to do is
solve the halting problem" bug.

And the value of putting on binders?  Well, sure... I don't mind
driving across various bridges.   That doesn't mean bridge designers
have the final say on mechanical engineering.