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!
