Create an interface between the engine and interpreter
sconybeare opened this issue · 10 comments
The lisp stuff will be have the world passed into it, and will therefore be able to call whatever functions it needs to. However, Seabass needs to know what those functions are so that they can exist. There should also be a function that will be called by the engine that performs a single beta reduction timestep's worth of beta reductions on a player's lisp code.
I disagree for the need to beta-reduce the code, and, regardless, that is a detail that is
a) Not desirable until the interpreter works properly
and
b) A job that the interpreter alone should care about
On Apr 20, 2014, at 4:08 PM, sebmathguy notifications@github.com wrote:
The lisp stuff will be have the world passed into it, and will therefore be able to call whatever functions it needs to. However, Seabass needs to know what those functions are so that they can exist. There should also be a function that will be called by the engine that performs a single beta-reduction on a player's lisp code.
—
Reply to this email directly or view it on GitHub.
How is code being evaluated if it isn't being beta-reduced?
Sorry - What I mean is that it doesn’t matter to the engine. All the engine needs to care about is exposing it’s API to the interpreter, as well as calling the interpreter for appropriate timesteps.
On Apr 20, 2014, at 4:26 PM, sebmathguy notifications@github.com wrote:
How is code being evaluated if it isn't being beta-reduced?
—
Reply to this email directly or view it on GitHub.
What it appears you want is a piece of code that advances the execution of the code by a single timestep.
As I understood it, our answer to non-halting player code was to perform a fixed number of beta-reductions during each timestep.
And yes.
So the answer is yes, but in terms of writing the interpreter it isn't necessarily a beta-reduction. For all the engine cares, one timestep could involve hundreds of beta-reductions, or some hodge-podge way of doing less than one. A timestep from the engine's point of view is just an arbitrary amount of execution time.
I agree, it should be a single timestep, not a single beta-reduction.
In terms of how exactly state will be represented, I'm thinking the AST, simplified by one timestep's worth of execution. So what the engine needs to keep track of is probably going to be the AST, which may be expanded to contain information about the environment that the code is running in (Basically what variables are defined at that point in time, in that scope).
The timestep's worth of reductions is included in c0393ec