Am I right that part of the issue is that executing Haxe code is done "fresh" for each run? That is, for a read-eval-print loop to be useful, you need to be able to (for example) assign a variable, then use it on a subsequent eval. Unless there's some explicit mechanism for keeping the execution state "active", and injecting the result of compiling each new expression into that environment, it's not possible to make read-eval-print work.
I think the main reason for read-eval-print is for experimentation and learning. Perhaps this approach would work: Instead of only compiling and evaluating the most recently typed expression, the latest expression would be appended to an ongoing "what has been done" log, and the entire "session" would be recompiled and executed as each input is done. Obviously, things would get slower and slower as you went on, but if this were the explicit model, you could go back into the session and remove or modify lines that weren't as desired. For example, you try calling a method and put its result in var <x>. You examine <x> and it's not what you want / expect. So you try a different way of calling the method, or you call a different method, and put that result in <x>. Re-running the entire set of inputs will call the method each way, setting <x> twice, not doing any significant damage to your understanding of what's happening. If you knew that this isn't your normal "interactive session" implementation, you know to overwrite your first attempt at creating <x> and thus the amount of work done next time does not grow so dramatically -- your mistakes aren't re-executed. One huge benefit of interactive sessions is that you can see the results of any experiments you did before as you construct new experiments -- unlike the situation where you change a "script file" and then load and re-run it -- when you make additions or changes to the script, you're only seeing your inputs and not the generated output. So the trick to having this work is making the "session log" distinguish between the code that's been (compiled and) executed and the displayed results, so that the editor supports (e.g.) moving up from a line of input past the output of the previous input in a single step; supports removing all output from one line of input in one step; color codes your inputs differently from the output, etc. (On April 1, I would add that an exercise for the reader would be to allow the user to change the part of the session log that represents a displayed result, rather than one of the inputs, and have the system re-write the "input line" so as to generate the desired result. That is, you say what you want and get the code that produces it.) J. Merrill Nicolas Cannasse <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 04/25/2008 08:51 AM Please respond to Neko intermediate language mailing list <[email protected]> To Neko intermediate language mailing list <[email protected]> cc Subject Re: [Neko] read-eval-print-loop possible? Eric Priou a écrit : >> But it's Neko only, there's no haXe read-eval-print loop available. > Is it a feature that you'll handle in haXe 2.0 ? That's not planned. It's more difficult to do since haXe is statically typed whereas Neko is dynamically typed. Nicolas -- Neko : One VM to run them all (http://nekovm.org)
-- Neko : One VM to run them all (http://nekovm.org)
