From: mailbox@dmitry-kazakov.de   
      
   On Fri, 19 Sep 2003 08:13:33 GMT, Don Geddis  wrote:   
      
   >"Dmitry A. Kazakov"  writes:   
   >> For text I/O due to its nature, nobody uses that, usually an   
   >> application exactly knows the type being input. So the code looks like:   
   >> X : Base_Type'Class := Read_From_Input;   
   >> Here Read_From_Input is responsible to detect the actual type.   
   >   
   >So let's try this example again, since you didn't get it the first time.   
   >I write a Read_From_Input function that gets some value from the user.   
   >It either returns integers, floats, or strings, depending on the syntax of   
   >what the user types.  (Double-quoted things become strings; digits with a   
   >decimal point become floats, digits without a decimal point become integers.)   
   >This is a perfectly well-formed function.   
      
   So where is a problem? Base_Type'Class should include two numeric   
   types and one string. Read_From_Input should read a literal of a   
   concrete Base_Type.   
      
   >Then later, I write some prototype code that calls Read_From_Input, and   
   >passes the result to Increment (which only takes integers or floats).   
   >   
   >This code cannot be proven safe with static type checks.  Yet, if the   
   >user happens to only type numbers, then it ought to run just fine.   
      
   Wrong, because Base_Type'Class includes strings, its specification   
   would have no Increment, which is detectable at compile-time. The   
   compiler does not know the concrete type but it knows what class of   
   types is to expect from Read_From_Input. So it can make and does   
   checks based on this knowledge.   
      
   >Your _insistence_ on static type checks is basically a claim that any   
   >("modern") compiler should _refuse_ to compile the code until the programmer   
   >makes more changes.  All I'm asking for is flexibility, to merely provide   
   >a static type warning, but compile the code anyway if that is more useful   
   >to the programmer's current needs.  Let the programmer make the decision   
   >about whether he wants to execute the code or not.   
      
   There is absolutely no need to execute an infeasible code.   
      
   >> >But that's exactly the case I outlined!  Increment is _not_ defined on   
   >> >all objects; only on numbers.  And you can't ensure that the Input will   
   >> >return only a number; the user might enter a list or symbol or some   
   >> >other non-number object.   
   >>   
   >> Then it will be a user fault, because the application *expects* a type   
   >> having Increment. IF a *legal* input should allow other types THEN the   
   >> program is incorrect. OTHERWISE, the input is *illegal* and this will   
   >> be signalled by raising an exception.   
   >   
   >Of course it's a user fault!  That was my point.  You can have programs which   
   >can't be proven type safe at compile time.  So your only choices are to   
   >refuse to compile them (if you're a "static type" language), or else do   
   >dynamic type checks at run-time.   
      
   This is a wrong picture. Statically typed laguages do not perform   
   *all* type checks statically. They only check what is statically   
   known. The rest is checked dynamically at run time.   
      
   This is why they comprise a more generic class of languages than the   
   dynamically typed ones. If in a given program, no type is statically   
   known, then a statically typed language acts *exactly* as a   
   dynamically typed one.   
      
   Again, not to check what can be checked is hardly an advantage. So   
   usually "dynamic" people rapidly switch to other issues. They claim   
   that they are able to compile the program more quickly. That they need   
   not to recompile a program and are accustomed to patch working systems   
   on the fly etc. All that quick'n'dirty stuff, which turns out much   
   more dirty and not that quick.   
      
   >> An incorrect probram may happen to work. Should it mean that it is   
   >> better to create programs using a random generator? Why should a   
   >> knowingly illegal program be compilable?   
   >   
   >You've gone too far.  There's a huge difference between "provably illegal",   
   >vs. "not provably type-safe".  Random generator programs may do anything.   
   >Whereas, a type-imperfect program may compute useful functions for some   
   >inputs (but not for others).  This partially-working program is _much_ more   
   >useful than a random program.   
      
   Where is a measure for that? A random sequence of bytes could appear   
   partially-working. Who knows, let's start and see! (:-))   
      
   >> The problem is that many AI programs perform a huge amount of   
   >> calculations over extremely large and tricky data structures. Consider   
   >> image processing or decision trees. Such programs are practically   
   >> impossible to debug using any convetional debugging tools.   
   >   
   >If you really believe this, then you either aren't a good programmer, or   
   >you don't have access to good debugging tools.  Perhaps you need to try a   
   >more interactive language, with powerful built-in introspection   
   >capabilities (to examine the current state of running image) -- like Lisp :-).   
      
   Well, try to debug an image compression program which works for 16x16,   
   but does not for 1024x1024. Good luck.   
      
   >> Often these programs are also concurrent.   
   >   
   >That's a different issue.   
      
   Real life has different issues...   
      
   >Debugging multiple threads is a much harder task,   
   >but I don't see how that's related to the issue we're discussing.  It's   
   >harder for everyone.   
      
   Consider thread-safe and thread-unsafe objects. In a language like   
   Lisp you can send them messages indiscriminately. What will happen, if   
   your program would concurrently send messages to an unsafe object? It   
   will randomly corrupt data depending on call timings. Typical is a   
   situation when it works under debugger, but sporadically crashes   
   whithout it. Now consider that the program makes a lengthy learning   
   process 2 week long and finally, when you are eager to see the result,   
   crashes and corrupts the data base.   
      
   >> Let I know that no reasonable program should sum apples and oranges,   
   >> then I have an ability to say the compiler to detect all such cases.   
   >> And this is just by specifying types. I don't feel this price being to   
   >> high.   
   >   
   >Why do you refuse to see the other side?  I grant that this style of   
   >programming can be useful at times.  I only claim that there also exist   
   >_other_ styles of programming, which are more appropriate for different   
   >kinds of applications.  And hence, I was recommending a language design which   
   >would let you apply whichever style of programming was most helpful to the   
   >problem in front of you.   
   >   
   >You keep giving me more examples of static type checking, which I was never   
   >arguing against.  I _agree_ that this can be a good thing, at times.   
   >   
   >Yet you continue to deny (or don't understand?) that there might be times   
   >where it isn't worth the effort.  Giving me more examples of the virtues of   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)