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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
