>> You don't need meta-programming technology (reflection) to do things >> like >> generic prinitng. A generic programming extension of Haskell (like >> Generic Haskell, or derivable classes) can do the job for you. > > Isn't generic programming usually based on a kind of compile-time > reflection (if the argument is of this type, do this, else..)?
Yes, you might view it as compile-time reflection. Programs are still typable. > And don't you write generic functions with the intention that the > implementation will figure out the approriate type-specific > variants, i.e., you write your code at a level of abstraction that > is not easily reached with the standard language tools -- a meta > level, where functions at different types are the first-class > objects of discourse? If you view that as a metalevel I agree. However, it is the intention you never see the generated functions at different types: the compiler can (in priciple) completely hide those from the programmer. In that sense there is just one level: Generic haskell offers you normal Haskell functions and generic functions. > I find it helpful to think of generic programming support as one way > of integrating well-behaved subsets of reflection and other > meta-programming techniques into Haskell. > > It is partly a trade-off: you get some of the features and avoid > some of the problems of a fully reflective architecture. It is also > a specialisation: by avoiding the full generality, the specific > subset of features can be designed in a structured fashion, with the > application domain in mind, making them easier to use for that domain. Agreed. -- Johan _______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
