Re: Interpret haskell within haskell.
On Friday 20 December 2002 03:16 pm, David Sankel wrote: I was referring to a haskell interpreter to be used within haskell code. For instance: main = do user_configuration - parseHaskell title - resolveFunction user_configuration title :: String putStr title My next language design will have such an uber-cool standard library that you will be able to evaluate all you want in the world. Now I've got some years of design work to be done if you will excuse me. exa -- who found out that C++ was the worst PL in the world after giving 7 years to it exa -- He also ditched his C++ like imperative OO language design that he wasted valuable time with -- Eray Ozkural [EMAIL PROTECTED] Software Engineer, BICOM Inc. GPG public key fingerprint: 360C 852F 88B0 A745 F31B EA0F 7C07 AE16 874D 539C ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Interpret haskell within haskell.
Lauri Alanko wrote on Dec 22: 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. I'm sorry to act as a Grinch, but there is no magic. First, according to R5RS, (interaction-environment) is not a first-class environment. R5RS says (Section 6.5): [[optional procedure]] (interaction-environment) This procedure returns a specifier for the environment that contains implementation-defined bindings, typically a superset of those listed in the report. The intent is that this procedure will return the environment in which the implementation would evaluate expressions dynamically typed by the user. There is nothing there about interaction between phases. And in fact, this interaction does not work. If you put the following code (module aaa) (begin (define a 5) (eval '(set! a (+ a 1)) (interaction-environment)) (display a) (newline)) into a file, _compile_ that file using Bigloo, and run the resulting a.out, you will see a message *** ERROR:bigloo:eval: Unbound variable -- a Nowhere the Scheme report talks about first-class environments. Please note that the result of (interaction-environment) is a _specifier_ for an environment. Some Scheme systems do provide first-class environments. For example, MIT Scheme has a form 'the-environment'. It comes at a price. In a post Re: why isn't the environment explicit ? on comp.lang.scheme on Mar 15, 2001, Joe Marshall wrote: Since you can (sort of) regard call/cc as making continuations explicit, why aren't environments explict ? In MIT Scheme, they are. The special form (the-environment) returns the current environment as a first-class object. However. The difficulty with using such a form is that it destroys any possibility of compiler optimization. If you compile code with a (the-environment) form in it (in MIT Scheme), the compiler essentially throws up its hands and inserts code to call the interpreter. There is no Santa either. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Interpret haskell within haskell.
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 [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Interpret haskell within haskell.
[[EMAIL PROTECTED]] David J. Sankel wrote: I was referring to a haskell interpreter to be used within haskell code. For instance: This was exactly the gist of the message: http://www.haskell.org/pipermail/haskell-cafe/2002-September/003423.html The message gave the working example. The end of the message posed that GHCi is better for these kinds of things. Simon Marlow's message shows that this is indeed the case. Unfortunately, as the message you cited admits (Perhaps someone will implement Staged Haskell one day?), it is hardly an elegant solution, and (I believe) it is not well suited to a large-scale application. Here's the best example I can come up with of what I'd hope to be able to address: suppose I love emacs, but hate lisp, and would love to have the benefits of static typing. I'd like to be able to write emacs with Haskell (or some appropriate variant) in place of elisp. This means I'd like to be able to bind keys to Haskell code (with type safety!) and so on. I'd like to able to enter a mode where the user could enter a read-eval-print loop and evaluate arbitrary expressions. These kinds of things are pretty much trivial with lisp, and what I'm basically asking is: is it possible to make them equally trivial (and similarly efficient) in a statically typed language. So, in my mind at least, forking a process and loading a new interpreter is not an acceptable solution. I suppose ghci packaged as a library, with a well-designed and appropriately granular interface would be OK, but of course it would be GHC-specific. I would also be curious to know the penalties one would have to pay in terms of performance, binary size, and so on, and I am also curious to know how easy it would be to add support for all the incidental functionality one would need to actually use it in a commercial app: e.g., how easy is it to grab, inspect and display useful error messages when loading code? Once again, I think it would be ideal if the standard library included data types and functions for reflection, staged evaluation/type-checking and so on. GHC, of course, could probably implement them using ghci, but I would like to maintain the delusion that eventually this stuff would work the same in any Haskell implementation. In the end, it seems like people ARE working on this problem, and it seems like it's really just not quite there. It also seems like I should probably stop talking about it unless I'm willing to invest a lot of time actually working on it. :) Thanks to all for the tips and the thoughtful responses. Matt -- Matt Hellige [EMAIL PROTECTED] http://matt.immute.net ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Interpret haskell within haskell.
On Fri, 20 Dec 2002, Matt Hellige wrote: [Christopher Milton [EMAIL PROTECTED]] --- David Sankel [EMAIL PROTECTED] 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 ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Interpret haskell within haskell.
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 [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Interpret haskell within haskell.
John Hughes [EMAIL PROTECTED] writes:
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).
A variant on this idea would be to use the 'Hugs Server API'. We used
to publicise this API on the Hugs pages but it seems to have gone
missing so you can grab a copy from:
http://www.reid-consulting-uk.ltd.uk/alastair/publications/server.ps.gz
You'll find a more up to date version in the Hugs distribution in
hugs98/docs/server.{tex,html}
The server API provides an interface for use from C programs but
Haskell's foreign function interface makes it a snap to access that
from Haskell.
There's only one caveat: you will have to use GHC or NHC to use the
Hugs server; you can't use Hugs to use the Hugs server. Bummer!
--
Alastair Reid [EMAIL PROTECTED]
Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Interpret haskell within haskell.
Lauri Alanko wrote (on 20-12-02 11:26 +0200): 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. :) 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. Here is just a sample. Just follow the bibliography trail, or use CiteSeer: Rowan Davies and Frank Pfenning. A modal analysis of staged computation. In POPL '96, pp. 258-270, 1996. Jean Goubault-Larrecq. Logical Foundations of Eval/Quote Mechanisms, and the Modal Logic S4. http://citeseer.nj.nec.com/goubault-larrecq97logical.html MetaML homepage http://www.cse.ogi.edu/PacSoft/projects/metaml/ Walid Taha. Multi-Stage Programming: Its Theory and Applications. PhD thesis, OGI, 1999. MetaOcaml http://www.cs.rice.edu/~taha/MetaOCaml/ (also see Related Systems at the bottom of this page) Tim Sheard and Simon Peyton Jones. Template Meta-programming for Haskell. Haskell Workshop, Pittsburgh, October 2002. Mark Shields, Tim Sheard and Simon Peyton Jones. Dynamic Typing as Staged Type Inference. POPL '98. Eugenio Moggi et al. An Idealized MetaML: Simple, and More Expressive. ESOP '99. Pierre Leleu. A Modal Lambda Calculus with Iteration and Case Constructs. http://citeseer.nj.nec.com/leleu97modal.html Philip Wickline, Peter Lee and Frank Pfenning. Run-time Code Generation and Modal-ML. PLDI '98. Hope this helps! Regards, -- Frank ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Interpret haskell within haskell.
--- Christopher Milton [EMAIL PROTECTED] wrote: --- David Sankel [EMAIL PROTECTED] wrote: I was wondering if there is any project that aims to interpret haskell within haskell. http://www.haskell.org/implementations.html quote type=partial GHC, the Glasgow Haskell Compiler The Glasgow Haskell compiler is a full implementation of Haskell. It is itself written in Haskell and is designed to act as a substrate for the research work of others. The source code is freely available. It produces fast code. /quote The GHC interpreter is ghci. (It's not as slow anymore.) http://www.haskell.org/ghc/ The other Haskell interpreters also load and interpret users' Haskell source code, as well. I was referring to a haskell interpreter to be used within haskell code. For instance: main = do user_configuration - parseHaskell title - resolveFunction user_configuration title :: String putStr title David J. Sankel ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Interpret haskell within haskell.
Hello, I am not sure to be relevant but I think : * This kind of thing would be very useful in Haskell, as this language has shown to be very usable to model foreign problems and do Domain Specific Language. It would, for example, allow to use a domain specific haskell script in an Haskell program. (For example, a DSL allowing to move a turtle on the screen and an haskell application showing the behavior of the turtle we have programmed. ) I think as soon someone want to script his application written in Haskell, he wants to script it using Haskell. * This feature should also allow to load a compiled haskell file to allow better performance by compiling scripts * I think these kinds of things are possible with a dirty hack : compile the script with ghc and dynamically load the .o file using Andre Pang's runtime loading. (can be found here http://www.algorithm.com.au/wiki/hacking/haskell.ghc_runtime_loading) This last solution is not type safe, but usable. Hope that can help, Cheers, Nicolas Oury ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Interpret haskell within haskell.
David J. Sankel wrote: I was referring to a haskell interpreter to be used within haskell code. For instance: main = do user_configuration - parseHaskell title - resolveFunction user_configuration title :: String putStr title This was exactly the gist of the message: http://www.haskell.org/pipermail/haskell-cafe/2002-September/003423.html The message gave the working example. The end of the message posed that GHCi is better for these kinds of things. Simon Marlow's message shows that this is indeed the case. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Interpret haskell within haskell.
--- David Sankel [EMAIL PROTECTED] wrote: I was wondering if there is any project that aims to interpret haskell within haskell. http://www.haskell.org/implementations.html quote type=partial GHC, the Glasgow Haskell Compiler The Glasgow Haskell compiler is a full implementation of Haskell. It is itself written in Haskell and is designed to act as a substrate for the research work of others. The source code is freely available. It produces fast code. /quote The GHC interpreter is ghci. (It's not as slow anymore.) http://www.haskell.org/ghc/ The other Haskell interpreters also load and interpret users' Haskell source code, as well. 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. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Interpret haskell within haskell.
[Christopher Milton [EMAIL PROTECTED]] --- David Sankel [EMAIL PROTECTED] 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. I previously inquired about using Haskell as an extension language, which is one application of this idea. There are many others. The ability to do this, and hopefully to do it in a simple, well-specified (and well-integrated into the rest of the language) way is perceived as a major benefit of using many high-level languages. The classic example, obviously, is lisp, where constructs to do exactly this are an integral part of the language's design. So it seems natural, especially to new users, to hope that Haskell and the ML variants, sharing many other features common to these languages, would offer this facility as well. The answer, in general, is that they do not. In many ways, this is a shame. In languages that support it cleanly, the ability to parse, manipulate and evaluate programs in an abstract, reflective way is wonderful. I suppose there's no need for examples, but I'd be happy to argue the point if there's disagreement. :) I know that I personally would love it if, as part of the language definition, Haskell and ML provided the ability to do these types of things. I'm not sure that I really understand all the reaons why this hasn't been done. I have some ideas, and I'd be very curious to know how far off the mark they are... In fact, I think this would make a wonderful Not-so-frequently Asked Question for the Wiki, if we could get together a good list of reasons why this is hard/inappropriate for Haskell. (If we can't, I nominate it to go into Haskell 2... :) In any case, here are my guesses at why Haskell doesn't have eval: - It is difficult to make the kind of run-time safety guarantees that we are used to with Haskell/ML if we introduce constructs of this kind. - It would seem to require considerable typing information to be carried around at run-time, which in general Haskell compilers seem to rely on being able to avoid. More generally, it may render unsafe a wide range of optimizing program transformations. - It would require the run-time for potentially every program to be considerably larger, carrying around an entire interpreter. - It has not, historically, been a priority for the community. The FP community has tended to focus more on safety and static analysis, as well as efficiency of compiled output. The general answer has been, Well, if you want that, you should be using lisp/scheme/etc. Are those reasons basically right, basically wrong, somewhere in the middle? If it's actually mostly the final reason, I wonder if the idea deserves more consideration. Has the idea been revisited in light of monadic control flow, type classes and other relatively recent developments? Would it be possible, in this case, to have our cake and eat it too? Matt -- Matt Hellige [EMAIL PROTECTED] http://matt.immute.net ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
