Most languages, even Java, have a reflection capability to dynamically inspect an object. _Even_ Java? That's a strange point of view considering how much money went into this technology.
they didn't take reflection seriously at first, initially providing only a half-baked feature set; that state, and the transition period when they finally noticed that they actually needed better reflection support for their own tools was somewhat painful (was it around/before jdk 1.2? partially coevolving with jni, debuggers, beans, etc.?).
I also find it hard to believe that most languages have reflection, especially those which are traditionally focused on efficiency and compilation to native code, like C, C++, Fortran, Pascal, etc.
c did have something like '&thing', providing you with the address of 'thing's representation, and in more innocent times, with the ability to read and rewrite that representation:-) c++ had templates, overloading if you doubt the expressive power of even such restricted reflection support, think of buffer overflow exploits or, in the scripting world, of string injection attacks. these are negative examples, but they demonstrate the potential of reflection support: to enable the unexpected, to support evolution of uses not originally planned for.
How many languages with reflection can you list?
you're kidding, right? lisp, prolog, smalltalk, clos' mop, java, javascript, sh, perl, .. well, most shells&scripting languages, and to a (sometimes very) limited extent, most languages however, that's a bit vague, and i always mix up the directions, so let me try to pin down some terms, so that we're at least mixed up the same way:-) - reification: from program/data to representation (reify, quote) - reflection: from representation to program/data (eval, splice) - meta-programming: programs operating on program representations - reflective programming: programs operating on their own representations unless i'm talking about specific operations/instances of the scheme, i tend to refer to the last item, encompassing all others, when i talk about reflection in programming languages. now, if you consider the old game of quines (programs printing their own representation), most turing-complete languages provide some reflection, the only question is, is it well supported or so awkward that its only uses are limited to theory papers and obfuscated code competitions?
I think the reasons are mostly insufficient resources and not enough interest to justify the effort.
the former, yes. the latter, no. the lisp/smalltalk folks have known all along, the java folks have found out the hard way, and some of us haskellers are still trying to pretend we do not know, even though we've been bitten often enough: - good reflection support makes it easy to develop tools and to experiment with language extensions - lack of good reflection support causes mutually inconsistent complex workarounds trying to reinvent reflection support the hard way while seriously hampering tool development anyone who tried to develop tools for haskell before the haskell implementations started to provide haskell apis to their inner workings can attest to the difficulties. whereas, the better these apis get, the less current developers are even aware that there used to be problems of that kind. and at the language level, we still use preprocessors, including the c one:-( btw, languages with adequate reflection support tend not to have separate preprocessors), we do have partial efforts like template haskell, data/typeable (and the generic techniques based on them, including scrap your boilerplate), in fact the whole type-class-level programming area could be said to be about type-based meta-programming generating functional programs from type-level proofs, then there are pragmas and implicit insertion of program markers for profiling/coverage analysis/debugging, complete program transformations for profiling/tracing/debugging, multiple separate frontends and ast types, language.haskell, hsx, programatica, poor man's versions of type dynamic, dynamic loading and runtime code generation, data.dynamic, hs-plugins, ghc api, yhc api, hugs server api, .. ah, well, you get the idea?-) perhaps the most important aspect of reflection support is to notice that there is a common theme in all these separate efforts, and a common support base that could help to make all of those efforts and similar tools/extensions/applications easier to develop, with the base designed to be consistent and maintained continuosly, in a single place, instead of developed and forgotten again and again. claus