Typical uses of reflection off the top of my head: 1. dependency injection: in Java/.NET, an xml file will provide fully qualified names designating types to satisfy various dependencies 2. serialization: reducing an object graph to some linear format and back, while preserving sharing 3. anything you'd use "deriving" for in Haskell, so generic Eq, Ord, Show, Read, etc. (show/read are just degenerate serialization to/from strings); basically, any function that can defined by structural induction on a type can be defined generically, so the Haskell generics literature has generic maps, folds, eq, etc. 4. runtime code generation typically reuses the reflection interface to designate types and type members 5. used to access metadata attached to types or type members, ie. declarative attributes can decorate classes, methods, fields, etc.; these attributes are used for all sorts of different purposes, although the runtime overhead means they're typically restricted to non-performance critical code and code generation 6. analysis: the reflection interface is sometimes used to analyze programs, eg. determining whether a type may be mutable
Many of these overlap, but #2 is the really critical one, and implies #1, ie. #2 requires loading types from a serializable type tokens of some sort. Once you can support full serialization with sharing to/from linear formats, most modern desktop and server applications become possible. I don't find attributes all that compelling, particularly not ones that have runtime impact. I don't expect BitC will support runtime codegen, so #4 probably isn't a consideration (although perhaps you would use it for link-time compilation?). #3 mostly implies #2, but is probably a step beyond what you want for BitC. It's pretty powerful though. You can write polytypic searches (find all Employee types given any structure) and polytypic updates (update all Employee salaries by X% given any structure). Sandro On 08/07/2014 3:31 PM, Sandro Magi wrote: > On 08/07/2014 10:15 AM, Jonathan S. Shapiro wrote: >> The other issue that emerges here is the problem of reflection. >> Reflection is very powertul and very useful, but its current form is >> malignant. Let's start another thread exploring what we might do about >> that. > This is a question I've read about quite a bit. Like most issues I've > found inprogramming languages, type-basedsolutions seem to be pretty > good. In terms of literature, we have: > > * polytypic programming: papers range from ML to Haskell with various > solutions. > * "generics" in Haskell: scrap your boilerplate, data types ala carte, > etc., but the best solution in terms of performance currently seems to > be associated types and type families combined with a new "deriving" [1,2]. > * first-class everything: basically, languages based on something like > the pattern calculus whereby every value is classified as either an atom > or a compound of atoms, and usual pattern matching can deconstruct > everything piecewise. > * metaprogramming in dependently typed languages is something I > haven't yet gotten to, but looks promising [3]. > > There are a number of issues reflection muddles together though, so it > really depends what you want to achieve. > > Sandro > > [1] http://dreixel.net/research/pdf/gdmh.pdf > [2] http://www.haskell.org/haskellwiki/GHC.Generics > [3] > https://lirias.kuleuven.be/bitstream/123456789/404549/1/icfp002-devriese-authorversion.pdf > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
