I wonder if it is possible to somehow turn D in to a scripting language that can be run inside D?

The point? To have the same uniform syntax for quickly developing scripts that can then be easily transferred, if desired, in to a complete binary.

e.g., suppose I am working in some type of analysis software. Use a Dscript like feature to develop and test different analysis algorithms quickly(rather than using the compile and execute model)... then once everything is working, move the code to a D file and compile it directly.

Since the syntax would be identical(or nearly so) it would be quite easy to copy and paste... unlike, say, using lua or some other non-D like scripting language.

On Friday, 2 June 2017 at 02:06:27 UTC, Mike B Johnson wrote:
> I wonder if it is possible to somehow turn D in to a scripting language that can be run inside D?

Why not just use regular compiled D?

On Friday, 2 June 2017 at 02:15:27 UTC, Adam D. Ruppe wrote:
> On Friday, 2 June 2017 at 02:06:27 UTC, Mike B Johnson wrote:
>> I wonder if it is possible to somehow turn D in to a scripting language that can be run inside D?
>
> Why not just use regular compiled D?


Because it requires one to recompile and relink the code for every change(and to possibly restart the app and redo all the work to get to some point to start testing the code). In a scripting engine one can simply call a function and execute commands immediately in an interactive way. This allows for much faster testing.


e.g., with a hypothetical app that has an interactive Dscript, one could do

> App.PlaySound("test123.wav");


instead of

1. change test12.wav to test123.wav
2. save file
3. recompile.
4. run
5. Get back to same test point(could be a lot or a little amount of work).


Regardless, that is not the point though. If that was the only reason, lua or some other scripting language would suffice.

The problem is that the grammars of all those languages do not translate directly in to D. Anglescript is a C++ like script that has a near 1-1 correspondence so "porting" code from it to C++ is easy.

But it would be nice if a D had a scripting language that used the same D syntax as this would make porting a piece of cake.


The point is, why should I develop, say, 100's of algorithms in the scripting language that can never easily be ported to native and be fast as possible simply because the of the amount of work to rewrite the code when, semantically, nothing changes?

Wouldn't it be much better to be able to confidently write the code in a scripting environment that allows for nearly instance response knowing that it can simply be recompiled to native without issue when the time comes for performance optimizations?

Anglescript effectively does this. Note only does it have a C++ like syntax, it has the ability to compile to native directly with an addon.

I'm looking for something like this in D because D's features are much better. having meta capabilities in scripting would be cool.

On Friday, 2 June 2017 at 02:32:43 UTC, Mike B Johnson wrote:
> 1. change test12.wav to test123.wav
> 2. save file
> 3. recompile.
> 4. run
> 5. Get back to same test point(could be a lot or a little amount of work).

If that is all you want; then compile your code into a dll/so and load the new version.
The D compiler is fast enough that it will not break your flow.

program-state management would be taken by the static part of your program.

On Friday, 2 June 2017 at 02:39:47 UTC, Stefan Koch wrote:
> On Friday, 2 June 2017 at 02:32:43 UTC, Mike B Johnson wrote:
>> 1. change test12.wav to test123.wav
>> 2. save file
>> 3. recompile.
>> 4. run
>> 5. Get back to same test point(could be a lot or a little amount of work).
>
> If that is all you want; then compile your code into a dll/so and load the new version.
> The D compiler is fast enough that it will not break your flow.
>
> program-state management would be taken by the static part of your program.

I thought about that but the state management would not be trivial and would prevent recompilation in most cases(because the state would not exist in the same format in recompiled version).  While it is possible, it doesn't seem like the way to go(and not only that, one doesn't get all the benefits a scripting language has(sandboxing, jit, etc).

We can come up with alternatives all day long but it will never fulfill the role...

On Friday, 2 June 2017 at 02:32:43 UTC, Mike B Johnson wrote:
> But it would be nice if a D had a scripting language that used the same D syntax as this would make porting a piece of cake.


So my script.d has kinda similar syntax, but fairly different semantics than good D code (though my jsvar.d provides a type to D that is very similar to the type in the script)...

Which means copy/paste might even compile, but it would be liable to work differently.

> I'm looking for something like this in D because D's features are much better. having meta capabilities in scripting would be cool.

Mine also doesn't do the meta stuff... yet. I could prolly add it easily enough but I never got around to it.


But I really think you can find a lot of use just using D itself. Make your application into some kind of library you can link to and you can be testing stuff in like a second from the time you write it.

anyway i g2g will talk more later

On Friday, 2 June 2017 at 03:33:37 UTC, Adam D. Ruppe wrote:
> On Friday, 2 June 2017 at 02:32:43 UTC, Mike B Johnson wrote:
>> But it would be nice if a D had a scripting language that used the same D syntax as this would make porting a piece of cake.
>
>
> So my script.d has kinda similar syntax, but fairly different semantics than good D code (though my jsvar.d provides a type to D that is very similar to the type in the script)...
>
> Which means copy/paste might even compile, but it would be liable to work differently.
>
>> I'm looking for something like this in D because D's features are much better. having meta capabilities in scripting would be cool.
>
> Mine also doesn't do the meta stuff... yet. I could prolly add it easily enough but I never got around to it.
>
>
> But I really think you can find a lot of use just using D itself. Make your application into some kind of library you can link to and you can be testing stuff in like a second from the time you write it.
>

I think that is more prone to errors and much harder to implement and maintain(assuming we had such a Dscript already).

If one could integrate it easily and well then possibly that could be Dscript...

1. Have ldc/dmd compile the "script"(D source) that exports, automatically, an entry point(main?). (easy)

2. Somehow allow different scripts to communicate(a real script doesn't have a problem with this, but a D app would need to "register" itself somehow). This could be easy or hard.

3. Link everything together(dll like stuff).

4. Passing of the hosting D app's context. this could be pretty hard to get right?

5. Allow for plug and play of the "dll's" generated... this could be tricky too.

Remember, we have to minimize all the junk code that won't be used in the D "equivalent" of the script. If one has to access all variables through some marshaling process and it slows down the code then we loose the ability to optimize by compiling to native code... which defeats the whole purpose.


Thoughts?

> anyway i g2g will talk more later


Ok, buddy! Thanks!

On Fri, 2017-06-02 at 02:39 +0000, Stefan Koch via Digitalmars-d-learn wrote:
> […]
> The D compiler is fast enough that it will not break your flow.
> 

This argument may work for you but it definitely doesn't work for me.

Using a language like Python, Groovy, Clojure, Lisp:

1. Edit
2. Run

With D and Go, both of which claim compilation so fast you do not notice:

1. Edit
2. Compile
3. Run

This is a 50% overhead (*). Even with LiteIDE and Gogland, you have the 3 stage sequence for Go programming, and it is a wee bit annoying.

If and only if you have continuous compilation without manual intervention, does Stage 2 go away. As far as I am aware there is currently no continuous compilation framework for D. Now using inotify , it should be possible. However Meson/Ninja, CMake/Ninja, SCons, etc. do not support this out of the box. IntelliJ IDEA and CLion should be able to support this, but D support isn't yet there out of the box (**).


(*) Clearly a fatuous number, but there is an election in UK, so fatuous statistics are order of the day.

(**) IntelliJ-Dlanguage project could always do with more eople working
on it.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Friday, 2 June 2017 at 04:50:00 UTC, Mike B Johnson wrote:
> 4. Passing of the hosting D app's context. this could be pretty hard to get right?

You'd ideally access the data through functions and shared value types instead of loading it directly. Then you can easily do it with shared libs or scripts or, best of all, an external process so if the "plugin" crashes, it doesn't crash the rest of the program.

This is a decent design for any program really, it decouples components and keeps private members private.

On Friday, 2 June 2017 at 09:39:51 UTC, Russel Winder wrote:
> With D and Go, both of which claim compilation so fast you do not notice:

1. Edit
2. run rdmd


Especially if you only expose to the "script" in D the same functions you'd expose to, say, a javascript script, that compile can be under a tenth of a second.

But 3/10 of a second isn't bad either and that's about what you'd get with an out of the box setup...