[Haskell-cafe] To yi or not to yi, is this really the question? A plea for a cooperative, ubiquitous, distributed integrated development system.

[Claus Reinke]

>> 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