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 <jules@jellybean.co.uk> 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