D run-time interpretation

[Jacob via Digitalmars-d]

On Tuesday, 6 October 2015 at 20:02:48 UTC, Jonathan M Davis 
wrote:
> On Tuesday, 6 October 2015 at 19:42:08 UTC, Jacob wrote:
>> There are many programs out there that use some sort of 
>> scripting capabilities.
>>
>> I've been wanting to write an app that exposes a scripting 
>> like environment D, lua, or some other fast language to the 
>> user.
>>
>> But there are two requirements:
>>
>> 1. The user has access to all objects created in app. e.g., if 
>> I create a class X in the app then the user can instantiate X 
>> in the script without having to recreate it. (the script then, 
>> is sort of an extension of the app)
>>
>> I don't mind actually having to expose X to the script, but it 
>> should be easy.
>>
>> 2. It should be fast. When it is "recompiled" it shouldn't 
>> take more than a few seconds. It also shouldn't require a 
>> re-initialization of everything.
>>
>> Can D do this easily?
>
> You know, you can use D as a scripting language. On Linux, you 
> do something like put
>
> #!/bin/rdmd
>
> at the beginning of the file, mark it is executable, and then 
> you can run it. I don't know what you need to put on the top to 
> make it work on Windows.
>
> These days, I write most of my scripts in D.
>
> - Jonathan M Davis


But this isn't what I want, only part.

Essentially I want to write an app that allows the user to 
"inteface" with the internals of the app, to control things and 
such.

Half the app is graphics and provides the backbone, sets up the 
graphics, deals with all that mess that the user doesn't need to 
deal with. The user, though, can control specific things such as 
the colors, objects, and such in the graphics scene. But instead 
of providing relatively static settings for the user(mess with 
sliders and such), I would like them to be able to specify what 
they want in "code".

e.g.,
User script code:

Graphics.Objects["Ship"].X = 10*cos(time);
Graphics.Objects["Ship"].Y = 10*sin(time);


...

So the user has the ability to access the "internals". Here 
Graphics is a sort of container for all the graphics, Objects is 
a map of all the objects in the scene.

But ultimately the code should be "compiled" in to the backbone 
of the app so it runs as fast as possible(not re-interpreted each 
scene).

One can think of it like this: The user provides code, the code 
is compiled as a function and the function called by the app. As 
long as one can link up the objects this should not be difficult.

If I were to do this by hand I'd have to write or use an 
interpreter or compiler(probably too slow) and provide a mapping 
of all the objects I want to expose(I'll have to "export" them 
from the app).

I could use something like LuaD, as I think it has the ability to 
parse strings as lua code, and the lua code can directly 
interface with the app. So this would not be that difficult to 
implement. The questions here are, is it fast enough and can it 
provide the simplicity I'd want.

I think C# has some type of compiler that allows one, in real 
time, to re-compile source code chunks and execute them as part 
of the program(not as separate entities that have no access to 
the underlying code).

This process would work but surely is too slow:

1. Treat the script code as pure D code.
2. Provide object references(pointers) to the objects I want to 
expose to the D code(as function arguments or through a lookup 
table or whatever)
3. compile the code into a dll.
4. Call the code in the dll per frame(or how ever I need to).


This would work great except the recompiling part and dll 
interfacing would surely be too slow. Since the user code could 
be modified often(modify a line, recompile), I need the changes 
to happen as fast as possible. If one wanted to modify the above 
code to

Graphics.Objects["Ship"].X = 10*sin(time);
Graphics.Objects["Ship"].Y = 10*cos(time);

I don't want the user to wait 5 mins while the app does all the 
work listed. Even, if it's 50 seconds it's still too slow.

I'd also like to use D as the scripting language since it would 
probably flow better(although, maybe lua and python could work 
too).

My app essentially has a visual scene representing the 3d 
graphics, and a "script editor" that allows the user to interact 
and modify the scene using code.

The scripting is crucial as it what makes the app what it is.