In the last coule of years there seems to be an increasing interest (or hype) regarding run-time 'relection' and/or run-time 'introspection'. (Are they the same thing?).

I think you mean "reflection" and yes, they are basically the same thing. Introspection tends to be more about "reading" and reflection tends to include "writing" or runtime generation of "things", but that is not a strict definition in any way.

There's nothing that can be done with run-time introspection that cannot be done (better) by compile-time decision taking.

First of all, this is silly, it is simply not that black and white a problem. Some problems can be solved very elegantly in dynamic languages like Perl/Python/Ruby, but are painful or just impossible in a stricter language like Java/Haskell/etc. and vice-versa.

There seems to be a lot of discussion of what it can do--in terms of "you can determine the type of something at runtime"--but little on why you would want or need to? And why it must be deferred to run-time?

Lets take a real world, highly useful usage of runtime introspection, a basic clone function (incomplete and simplified of course).

sub clone {
    my ($value) = @_;
    if (ref $value) {
        if (blessed $value) {
            if ($value->can('clone')) {
                return $value->clone;
            }
            else {
                die "Sorry object is not cloneable";
            }
        }    
        else {
            if (ref $value eq 'ARRAY') {
                return [ map { clone( $_ ) } @$value ];
            }
            elsif (ref $value eq 'HASH') {
                return { map { $_ => clone( $value->{$_} ) } keys %$va
+lue };
            }        
            else {
                die "Sorry cant clone that $value";
            }
        }
    }
    else {
        return $value
    }
}
[download]

Every single one of those calls to ref and to can is runtime type introspection. Could you defer that to compile-time? Sure, but only by adding more facilities to the language to support that. Here is a Perl6-ish version of the above code using multi-methods:

multi sub clone (Object where { $_->can('clone') } $value) {
    return $value->clone;
}
multi sub clone (Scalar $value) {
    return $value;
}
multi sub clone (ArrayRef $value) {
    return map { clone($_) } @$value;
}
multi sub clone (HashRef $value) {
    return map { $_ => clone( $value->{$_} ) } keys %$value;
}
[download]

Now the compiler could aggressively compile your program to the point whereby it could find every point at which clone was called and look at what $value contains and "unroll" that code therefore making all the decisions at compile time. But that is a lot of work and a lot of static analysis on the compilers part, and that kind of analysis only works if the language your analyzing has a strong theoretical foundation. For instance, with the above multi-method code, in order for that to work, all those types must be part of the same type "set", and in order for the compiler to actually generate efficient code you must provide a branch for each member of that set, which I clearly am not. Maybe my compiler could infer those missing conditions? Well thats nice assuming it got them right, but how can i be sure? If you have ever really tried to hack with Haskell or Ocaml you will know exactly what I am talking about.

Okay, so my point here is that you have a waterbed. If you push it down on one side (moving the runtime checks to compile time), it pushes up on the other side (now your compiler is much more complex and you have a type system to fight with). There is no one right solution to this problem, it is balance that has to be struck by the compiler writer/language designer as to where they want their complexity to be.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.