On static and dynamic typing, and corn tortillas

---

12 Comments:

1. Greg Buchholz - January 9, 2007:

   You might really want to check out a language with a more modern type system. Something like Haskell, ML, Mercury, Omega, etc. A lot of the problems you see with static typing seem to be more related to Java's limitations. In you "array with failures" example, you'd probably use something like the Option type in ML, or the Maybe type and monad in Haskell. Or with your "passing functions as parameters", even C++ doesn't require you do declare the full signature of the function parameter. "template removeAppendix(Patient p, Func reportError)" will do.

2. Greg Buchholz - January 9, 2007:

   Oops, that's

   template<class Func> removeAppendix(Patient p, Func reportError)

3. Patrick - January 9, 2007:

   Thanks for the pointers. You're right, I should take a look at those languages. I have poked around with Haskell and OCaml, but only the tiniest bit.

   In your C++ example, is the type of the function still checked statically?

4. Greg Buchholz - January 9, 2007:

   In your C++ example, is the type of the function still checked statically?

   Yes. I don't think I've ever seen a formal definition of duck typing, but C++ templates certainly allow you to treat anything that quacks and waddles as a duck, while still making sure your type mismatches are detected at compile time. Same goes for Haskell, Clean, etc.

5. Patrick - January 10, 2007:

   I assume you're referring to type compatibility in those static type systems?

6. Greg Buchholz - January 10, 2007:

   I assume you’re referring to type compatibility in those static type systems?

   If by "type compatibility" you mean types that can substitute for one another everywhere, then no. In Haskell, for example, you can create a function...

   double x = x+x
   

   ...which can be passed anything that understands the plus operator. So lets make lists of numbers understand "plus"...

   instance Num a => Num [a] where (+) = zipWith (+)
   

   ...now let's try it out at the REPL...

   $ ghci type_compat.hs 
      ___         ___ _
     / _ \ /\  /\/ __(_)
    / /_\// /_/ / /  | |      GHC Interactive, 6.6, for Haskell 98.
   / /_\\/ __  / /___| |      http://www.haskell.org/ghc/
   \____/\/ /_/\____/|_|      Type :? for help.
   
   Loading package base ... linking ... done.
   [1 of 1] Compiling Main          ( type_compat.hs, interpreted )
   
   Ok, modules loaded: Main.
   *Main> double 4.0
   8.0
   *Main> double 42
   84
   *Main> double [1,2,3]
   [2,4,6]
   *Main>
   

   ...so you can use floating point numbers and lists of integers in some of the same places, but I don't think they'd be called compatible types.

7. Patrick - January 10, 2007:

   What I meant by type compatibility is that the compiler is able to determine that a type has a specific interface (in your example, that it understands the + operator) without any sort of explicit declaration.

   In short, your example is exactly what I meant. Thanks.

8. Greg Buchholz - January 11, 2007:

   Here's the similar thing in C++ which will work with lists of doubles, lists of lists of ints, etc...

   #include<iostream>
   #include<list>
   #include<iterator>
   
   using namespace std;
   
   template<class T> T p(T a, T b){ return a+b; }
   template<class T> list<T> operator+(list<T> a, list<T> b)
   {
      list<T> out;
      transform(a.begin(),a.end(),b.begin(),back_inserter(out),p<T>);
      return out;
   }
   
   int main(int argc, char* argv[])
   {
       double x[] = { 1.0, 2.0, 3.0};
       double y[] = {10.0,11.0,12.0};
       list<double> a(x,x+sizeof(x)/sizeof(double));
       list<double> b(y,y+sizeof(y)/sizeof(double));
       list<double> c;
   
       c = a+b;
   
       copy(c.begin(),c.end(),ostream_iterator<double>(cout, "\n"));
   
       return 0;
   }
   

9. Greg Buchholz - January 11, 2007:

   Here's a better operator+ for that example...

   template T operator+(T a, T b)
   {
      T out;
      transform(a.begin(),a.end(),b.begin(),back_inserter(out),
                p);
      return out;
   }
   
   

10. Greg Buchholz - January 11, 2007:

    Here's a better operator+ for that example (now with angle brackets)...

    template<class T> T operator+(T a, T b)
    {
       T out;
       transform(a.begin(),a.end(),b.begin(),back_inserter(out),
                 p<typename T::value_type>);
       return out;
    }
    
    

11. Patrick - January 11, 2007:

    Ok, but in those examples, what happens if you instanitate a list, where MyClass doesn't implement operator+?

12. Greg Buchholz - January 11, 2007:

    You get a compiler error.