Simon Marlow wrote:
The test driver makes use of 'eval'-style scripting, which none of the existing Haskell systems has.
Doesn't the following qualify as eval? A similar code works even in Hugs.
import System (system, ExitCode(ExitSuccess)) import Posix(executeFile)
myconfig_file = "/tmp/config"
phaseII_var = "/tmp/Config.hs" phaseII_const = "/tmp/a.hs" phaseII_eval = "ghc --make " phaseII_result = "/tmp/a.out"
nl = "\n"
writeConfig :: Int -> IO () writeConfig num = do writeFile phaseII_var $ concat ["module Config (config_item) where", nl, "config_item =", show num, nl]
runSuperIO () = system (phaseII_eval ++ phaseII_const ++ " -o " ++ phaseII_result) >>= \ExitSuccess -> executeFile phaseII_result False [] Nothing
main = readFile myconfig_file >>= writeConfig . read >>= runSuperIO
The context: http://www.haskell.org/pipermail/haskell-cafe/2003-February/003912.html Furthermore, if GHCi can (after some prodding by the user) launch ghc to compile a module and then load the resulting .o file in and apply some function in thus loaded file, doesn't it feel like an eval?
On Fri, May 30, 2003 at 07:57:57PM -0700, oleg@pobox.com wrote:
The context: http://www.haskell.org/pipermail/haskell-cafe/2003-February/003912.html
Furthermore, if GHCi can (after some prodding by the user) launch ghc to compile a module and then load the resulting .o file in and apply some function in thus loaded file, doesn't it feel like an eval?
I noticed that GHCi forgets all defined variables after loading any modules - this can be a (probably minor) problem. I don't know how it works in Python, but in perl the code in eval is executed in current lexical scope. I think it could be difficult to emulate this in a language like Haskell. Hmmm, GHCi seems to do that internally, so maybe it could be possible, but the resulting extension would work only in interpreted mode. Best regards, Tom -- .signature: Too many levels of symbolic links
Tomasz Zielonka wrote:
I don't know how it works in Python, but in perl the code in eval is executed in current lexical scope.
Eval of the kind let x = 1 in eval "x" is plainly an abomination. Such an eval all but precludes compilation because the compiler is not free to alpha-rename lexical bindings any more and cannot eliminate bindings by inlining. Incidentally, the eval in Scheme does not (and cannot, in general) use let-bindings. Scheme's eval may consult previously declared top-level bindings -- but only given an appropriate flag (whose existence is entirely optional). Incidentally, restricting eval to top-level or "standard" bindings is not a significant limitation. It is, in general, a very good practice to apply eval to closed expressions only. For example, let x = 1 in (eval "\x->x") x or y = 1 main = (eval "let x = " ++ (show y) ++ " in x" ) >>= putStrLn or (if we need to pass many parameters) y = 1 z = 2 do writeFile "Conf.hs" $ makeBindings [["y", show y],["z", show z]]; result <- eval "import Conf;y+z"; putStrLn result Thus if we restrict all parameters for eval to be in the class Show/Read, we can implement such an eval right now. P.S. It has crossed my mind to suggest Scheme as a driver for the regression tests -- using Ashley Yakeley's HScheme system. I know of several commercial projects that use Scheme to drive regression tests for Java projects (Scheme being implemented in Java itself).
[oleg@pobox.com]
Furthermore, if GHCi can (after some prodding by the user) launch ghc to compile a module and then load the resulting .o file in and apply some function in thus loaded file, doesn't it feel like an eval?
Yes, I think both of your solutions are workable in principle and in certain practical settings, but they are both pretty heavy. In a language that encouraged the use of eval, I would hope it would be a considerably less expensive operation. My feeling is that as long as it's non-standard and heavy, eval will not become idiomatic in Haskell, and programmers who desire/require a lightweight eval will continue to look elsewhere. Further, these workarounds offer only the most rudimentary ability to handle errors or other exceptional conditions. Incidentally, it would be my enormous preference for eval to work on a structured representation of an expression rather than a string. This is one area where the weakness of Python-style eval is really exposed, when compared to Lisp. I'd suggest re-using the new stuff that has been introduced for template-Haskell here, and keeping parsing separate. Matt -- Matt Hellige matt@immute.net http://matt.immute.net
Hello Matt, Monday, June 02, 2003, 17:16:41, you wrote: MH> Incidentally, it would be my enormous preference for eval to work on a MH> structured representation of an expression rather than a string. This then you should take a look into `C (tick C) `C and tcc: A Language and Compiler for Dynamic Code Generation Massimiliano Poletto & Wilson C. Hsieh http://www.cs.utah.edu/~wilson/papers/tickc.pdf here guys tries to implement efficient eval facility for C language -- Best regards, hw mailto:hw@ksue.edu.ua
participants (4)
-
hw -
Matt Hellige -
oleg＠pobox.com -
Tomasz Zielonka