Re: OT: Language War (Re: "C" Manual)

[Richard Cobbe <cobbe@airmail.net>]

Lo, on Tuesday, January 1, dman did write:

> On Mon, Dec 31, 2001 at 09:27:36PM -0500, William T Wilson wrote:
>  
> | Casting you can't really get away from nor do you really need to.  In fact
> | the more strongly typed the language is, the more casting you have to do.
> 
> This statement is incorrect.

Agreed.

> The strength and staticness of typing are two independent properties.

Also agreed.

However, I think that the flexibility of a type system is more important
than its `strength' for removing the need for casts.

When do people use typecasts in C/C++?  In my experience, they tend to
happen in the following situations:

  1) conversions between data types (char and int, int and float, etc.)
 
  2) downcasts in a class hierarchy, as in Java.  (Note that `upcasts'
     aren't really casts: if B is a subclass of A, then an instance of B
     *is* an instance of A, no cast needed.)

  3) Accessing external data in a callback function.  Callbacks in C and
     C++ often take a void* parameter that points to data supplied by
     the programmer when he registers the callback; to access this data,
     it is necessary to cast it back to the original type.

How do more flexible type systems handle these?

  1) There are conversion functions.  Scheme does this with, e.g.,
     char->integer and integer->char, or exact->inexact and
     inexact->exact.  (The latter two convert between integers and
     floating point numbers.)  In many cases, this is what C's casts and
     C++'s static_cast really do; they just use a typecast notation.
     Many programmers tend to follow this trend when writing their own
     conversions, although I usually don't---implicit conversions worry
     me.

  2) As several people have pointed out, too many downcasts indicate a
     design flaw.  They are, however, useful in some situations, so (I
     believe) many advanced languages with a static type system support
     these.  However, as in Java, there's a run-time check that goes
     with it.  C++'s dynamic_cast gets this right.

  3) There are a variety of strategies here.  My personal favorite is
     to use first-class closures to implement callbacks; the external
     data is no longer supplied as a parameter but is simply available
     to the callback function due to normal scoping rules.  If you're
     using a language without closures, like C++ or Java, you can hack
     it up:

     class Closure
     {
     public:
         virtual void invoke(void) = 0;
     };

     Subclass this, implement invoke(), and supply a reference to the
     subclass instance as your callback function.  The data normally
     recognized by the void* is now private data members in the callback
     instance; no cast necessary.

     Alternatively, supply the callback system with enough smarts to
     handle types.  Instead of

        void register_callback(void (* cb)(void *), void *data);

    write something like

        template<typename T>
        void register_callback(void (* cb)(T), T data);

    although most advanced languages typically use a more concise
    mechanism for this sort of polymorphism.

With the exception of downcasts, casting is generally only necessary if
your type system isn't very expressive.

> I've heard that haskell has an even better type system, but I haven't
> had time to learn it yet.

Most of my experience with advanced programming languages has been in
Scheme, which (despite what many people believe) *is* strongly-typed and
type-safe, but it checks all types at runtime rather than compile time.
As a result, I'm not really up on languages with compile-time type
verifications systems, though I've been meaning to investigate them for
a while now.  At any rate: I've heard that ML's type system is easier to
learn than Haskell's; you may want to start there first.

Richard