|
List Info
Thread: Re: read-eval-print-loop possible?
|
|
| Re: read-eval-print-loop possible? |
 
United States |
2008-04-25 08:29:35 |
|
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 <ncannasse motion-twin.com>
Sent by: neko-bounceslists.motion-twin.com
04/25/2008 08:51 AM
Please respond to
Neko intermediate language mailing list <nekolists.motion-twin.com> |
|
To
| Neko intermediate language mailing list
<nekolists.motion-twin.com>
|
|
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)
|
[1]
|
|
|
about | contact Other archives ( Real Estate discussion Medical topics )
|