On Fri, 20 Dec 2002, Matt Hellige wrote:

[Christopher Milton ]

...

--- David Sankel wrote:

...

I was wondering if there is any project that aims to interpret haskell within haskell.

[... snipped intro to ghci ...]

...

If you have defined functions in "myprog.hs": :load myprog.hs then the functions defined in the file are available, or else you'll get error message(s) about problems found parsing "myprog.hs".

I'm not sure this is quite what he's asking for. For many projects it is useful to be able to dynamically (and programatically) load and evaluate arbitrary chunks of code for one reason or another.

Maybe this isn't quite what he was asking for either, but... When I want to do this kind of thing, I use hugs as a back-end. I write the expressions I want to evaluate, or whatever, to a file of hugs commands, and then run system "hugs <hugsinput >hugsoutput" then read and process the output (choose your favourite filenames, /tmp/... or whatever). It's not the world's fastest solution, but on the other hand hugs provides excellent "reflection" -- you can do much more than just evaluate expressions, you can ask hugs about types, class instances, etc etc. I've used this, for example, in an old prototype JavaDoc like tool which used Hugs to determine the types and other properties of documented names, and in a little script for use with QuickCheck, which finds all the property names defined in a set of modules, loads the modules into hugs, and tests the properties. You may think this is a very simple-minded approach, but I would defend it on several grounds: * it is VERY simple, and provides "programmatic eval" without any semantic problems whatsoever. * knowledge of the Haskell language is isolated where it belongs, in the hugs interpreter -- my tools only need to know how to work the hugs interface. As the language evolves, I can keep up just by installing a new version of hugs -- I have no parser and interpreter of my own to maintain. Easy and effective -- if a bit slow. John Hughes

For what it's worth, I will probably be doing my MSc thesis on adapting eval (and reflection in general) to a statically typed language. Essentially you need a run-time representation of the environment and the typing context, and a type system which groks the relationship between run-time and static types. Strangely enough, I haven't found any real research on this particular subject. There's lots of work on related areas, eg. dynamic types and intensional polymorphism, but nothing that's really motivated by eval and reflection. Any suggestions for references are welcome. :) Lauri Alanko la@iki.fi

On Fri, Dec 20, 2002 at 01:43:07PM +0100, Frank Atanassow wrote:

There is quite a bit of work on staged evalution, metaprogramming, quasiquotation, reflection and run-time code generation in typed and ML-like languages. It's a very active and, IMO, promising area of research.

Yes. Thanks for the references, some of them I hadn't been acquainted with. I was already aware of MetaML, but I had mostly thought of it as a sophisticated macro system. But of course if you defer some stages until "runtime" you essentially get _some_ form of eval. After quickly skimming through some of these papers, it seems that they aren't really after the same thing as I am. Template Haskell is explicitly a macro system, and MetaML seems to be designed for partial evaluation so that even at the first stage (in the source code) we have _some_ idea of the structure of the code that is to be generated. Specifically, it seems that there is no way to dynamically generate identifiers from strings, and I guess this makes real evaluation of arbitrary input impossible. Staged computation is very interesting in its own right, but I'm after something different. I don't really want eval as a language construct, I want a language that makes it possible to _implement_ eval, among other things. Let's take Scheme for an example. R5RS Scheme includes eval, but by itself it's not particularly interesting. An interpreter for a language is just a program, after all, and a full scheme evaluator can be implemented in a couple of hundred lines. So there's nothing magic about this: (eval '(letrec ((fact (lambda (x) (if (zero? x) 1 (* x (fact (- x 1))))))) (fact 5)) (scheme-report-environment 5)) ==> 120 The magic is _here_: (begin (define a 5) (eval '(set! a (+ a 1)) (interaction-environment)) a) ==> 6 Here (interaction-enviroment) is a run-time representation of the compile-time environment. It makes possible two-way interaction between the stages. Essentially, first-class environments are all the magic you need to implement eval. So what I'm looking for is adapting first-class environments, as well as other forms of reflection that are found in lisps, Smalltalk, Java, and other untyped languages, to static typing. And I want to do it properly with minimal run-time checking: eval :: Pi t . String -> Env -> Maybe t Here "t" is an explicit run-time type parameter, and 'eval t s e' returns 'Just x' if 's' represents a well-formed expression that can be assigned type 't' in the environment 'e' and reduces to 'x'. There are lots of other issues, of course. But the point is that I'm not so much interested in code-generation mechanisms but rather in how to reify compile-time information on the program as run-time objects. Optimally, I'd like a system that allows the definition of new types at runtime and possibly even gradual hot-swapping of the entire codebase of the program. All with type-safety. So is there any research on this sort of thing? (This isn't really Haskell-specific, so this is probably somewhat off-topic for haskell-cafe. Sorry about that, but I don't really know of a better place to discuss this. When I tried to query about this on the Types forum, the moderator rejected my posting as "too rambling", which was of course perfectly accurate :). I haven't yet managed to write up a more lucid exposition of the issue...) Lauri Alanko la@iki.fi