Re: [Haskell-cafe] haskell and reflection
lgreg.meredith: Haskellians, Am i wrong in my assessment that the vast majority of reflective machinery is missing from Haskell? Specifically, * there is no runtime representation of type available for programmatic representation * there is no runtime representation of the type-inferencing or checking machinery * there is no runtime representation of the evaluation machinery * there is no runtime representation of the lexical or parsing machinery So there is library support for all of this, in various forms: * lexer, parser, type checker, evaluator: ghc-api hs-plugins * lexer, parser, pretty printer many parser libs (Language.Haskell, Template Haskell) * runtime type representation Data.Typeable * reflecting code to data: Data.Generics -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell and reflection
Hi there is no runtime representation of type available for programmatic representation Data.Typeable.typeOf :: Typeable a = a - TypeRep there is no runtime representation of the type-inferencing or checking machinery Pretty much, no. The GHC API may provide some. there is no runtime representation of the evaluation machinery Yhc provides some representation with the Yhc API. there is no runtime representation of the lexical or parsing machinery lex provides some of this. There are various Haskell parsers out there in packages for us. I wouldn't have considered these things reflection - certainly the Java/C# use of the word reflection is quite different. Data.Generics does provide many of the reflection capabilities of Java. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell and reflection
Neil, Thanks very much for the detailed response. When we did Rosette, a reflective actor-based language, back in the late '80's and early '90's, we were very much influenced by Brian Cantwell Smith's account of reflection in 3-Lisp and similarly by Friedman and Wand's Mystery of the Tower Revealed. Our analysis suggested the following breakdown - Structural reflection -- all data used in the evaluation of programs has a programmatic representation - Procedural reflection -- all execution machinery used in the evaluation of programs has a programmatic representation The Java notion of reflection is restricted entirely to the first case and then only to the data used once a normalized representation has been achieved. In fact, lexing and parsing are of considerable interest and complexity in the evaluation of programs and reflective access is extremely useful. Likewise, access to the evaluation machinery itself is of more than theoretical interest. For example, in an ATM network management system i wrote in Rosette, i used reflective methods -- where the evaluation itself could be captured, stored and manipulated, much like a 1-shot continuation -- to make a polling interface of an external trouble-ticketing system we were required by business constraints to interface with look like an interrupt-driven interface to the Rosette-based clients. Best wishes, --greg On 9/11/07, Neil Mitchell [EMAIL PROTECTED] wrote: Hi there is no runtime representation of type available for programmatic representation Data.Typeable.typeOf :: Typeable a = a - TypeRep there is no runtime representation of the type-inferencing or checking machinery Pretty much, no. The GHC API may provide some. there is no runtime representation of the evaluation machinery Yhc provides some representation with the Yhc API. there is no runtime representation of the lexical or parsing machinery lex provides some of this. There are various Haskell parsers out there in packages for us. I wouldn't have considered these things reflection - certainly the Java/C# use of the word reflection is quite different. Data.Generics does provide many of the reflection capabilities of Java. Thanks Neil -- L.G. Meredith Managing Partner Biosimilarity LLC 505 N 72nd St Seattle, WA 98103 +1 206.650.3740 http://biosimilarity.blogspot.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell and reflection
Greg Meredith wrote: Haskellians, Am i wrong in my assessment that the vast majority of reflective machinery is missing from Haskell? Specifically, * there is no runtime representation of type available for programmatic representation * there is no runtime representation of the type-inferencing or checking machinery * there is no runtime representation of the evaluation machinery * there is no runtime representation of the lexical or parsing machinery As far as they go, those are true. Haskell compiler are permitted to erase types and GHC does so. There is no need to check types at runtime; that's the point of the system! There is no evaluator, or parser, built in to the standard libraries. (The lexer, or a version of it, is embedded in actual fact but that's not very exciting). However, one should not draw too strong negative conclusions from this. It is possible to get suprisingly far with more powerful, more typesafe techniques without surrendering the the pure dynamism of languages that lack compile-time guarantees. Deriving Typeable and Data is one tool which is useful. It is quite possible to embed a haskell compiler, see hs-plugins. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell and reflection
Jules, Thanks for these comments. i wouldn't judge Haskell solely on the basis of whether it embraced reflection as an organizing computational principle or as a toolbox for programmers. Clearly, you can get very far without it. And, it may be that higher-order functional gives you enough of the 'programs that build programs' capability that 80% of the practical benefits of reflection are covered -- without having to take on the extra level of complexity that reflection adds to typing. i was really just seeking information. Best wishes, --greg On 9/11/07, Jules Bean [EMAIL PROTECTED] wrote: Greg Meredith wrote: Haskellians, Am i wrong in my assessment that the vast majority of reflective machinery is missing from Haskell? Specifically, * there is no runtime representation of type available for programmatic representation * there is no runtime representation of the type-inferencing or checking machinery * there is no runtime representation of the evaluation machinery * there is no runtime representation of the lexical or parsing machinery As far as they go, those are true. Haskell compiler are permitted to erase types and GHC does so. There is no need to check types at runtime; that's the point of the system! There is no evaluator, or parser, built in to the standard libraries. (The lexer, or a version of it, is embedded in actual fact but that's not very exciting). However, one should not draw too strong negative conclusions from this. It is possible to get suprisingly far with more powerful, more typesafe techniques without surrendering the the pure dynamism of languages that lack compile-time guarantees. Deriving Typeable and Data is one tool which is useful. It is quite possible to embed a haskell compiler, see hs-plugins. Jules -- L.G. Meredith Managing Partner Biosimilarity LLC 505 N 72nd St Seattle, WA 98103 +1 206.650.3740 http://biosimilarity.blogspot.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell and reflection
On Tue, Sep 11, 2007 at 07:33:54AM -0700, Greg Meredith wrote: Our analysis suggested the following breakdown - Structural reflection -- all data used in the evaluation of programs has a programmatic representation - Procedural reflection -- all execution machinery used in the evaluation of programs has a programmatic representation The Java notion of reflection is restricted entirely to the first case Then what would you call ClassLoader.defineClass? As for Haskell, there are various tools for both (at least Data.Typeable and hs-plugins), but neither are truly type-safe: it is possible to write code that uses these libraries and type-checks, yet crashes. Static typing makes reflection very difficult to support safely. You might be interested in my MS thesis, where I explored these issues in some more length: http://www.cs.helsinki.fi/u/lealanko/alanko04types.pdf Lauri ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell and reflection
Op 11-sep-2007, om 18:43 heeft Greg Meredith het volgende geschreven: Thanks for these comments. i wouldn't judge Haskell solely on the basis of whether it embraced reflection as an organizing computational principle or as a toolbox for programmers. Clearly, you can get very far without it. And, it may be that higher-order functional gives you enough of the 'programs that build programs' capability that 80% of the practical benefits of reflection are covered -- without having to take on the extra level of complexity that reflection adds to typing. i was really just seeking information. Template Haskell [1] is a system that lets you write programs that get executed at *compile time*, and that produce parts of the Haskell program to be compiled by manipulating a representation of the program as structured data. It's a form of reflection restricted to compile time, if you'd ask me. Regards, Reinier [1] http://www.haskell.org/haskellwiki/Template_Haskell ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
