Walter Bright Wrote:

> strtr wrote:
> > Scripting in de form of a dialect/subset of D in the std/language.
> > I don't know enough about scripting to say anything specific/useful.
> > It's just that if scripting were part of D, I would have used it already where the possibilities mentioned by Robert Clipsham just look that much bigger a step.
> > And being part of the language/community simply instils trust.
> 
> I thought about that a lot, but CTFE seems to fill that gap well enough.

I don't think CTFE fills the gap of RTFE.
I need the scripting for my users and they can't compile the program :)
Maybe you are talking about another gap.
Now, choosing a scripting language feels like a stab in the dark and I can't put it off forever :)

Walter Bright:
> I thought about that a lot, but CTFE seems to fill that gap well enough.

CTFE works at compile-time, while people add scripting languages like Python, JavaScript, Groovy, Jpython, Jruby, etc, to run-time C/C++/Java code for other purposes. For example games are often written in C++ and Lua. For example Firefox is C++ and JavaScript, ecc. You can't write one million of lines of D CTFE code to script a 3D videogame. So unless you leave the compiler beside the running program, and you allow to dynamically interpret and run D code at runtime, the purposes are very different.

So I think embedding/extending D2 with a scripting/dynamic language (like MiniD o Python with Pyd) will be useful for some future D projects. But I don't want it built-in, people will find ways to attach it as they do to C/C++/Java. You have to focus in building a good D language.

What I think I'd like in D is something like this, but I think there's no need to use JavaScript for this, it can be used just D code:
https://developer.mozilla.org/en/Treehydra

Bye,
bearophile

On 3/29/10, Robert Clipsham <robert@octarineparrot.com> wrote:
> I seem to recall it is, and a fairly old D1 at that... You could always update it and send a patch Walter's way, see if he accepts it :)

Walter seems to have fixed it up the the new D1; it compiled there.

And I just spent the day making a port to D2. There's a few WTFs in there though, which I hacked around.

Here it is:
http://arsdnet.net/dcode/dmdscript_d2.zip

First, once each in dobject.d and script.d, I casted away a const. grep for FIXME.

Second, and this is the big one: the assocative array implementation in there seems to have broken entirely with the switch to D2. Look for "BIG HACK" in property.d - I had to do this two times:

	assert(key !is null);
	p = *key in table;

	// BIG HACK! in seems broken!
        if(p is null)
	foreach(k,ref v; table) {
		if(k.toString() == key.toString()) {
			p = &v; // WTF
			break;
		}
	}

Previously, it used a custom AA implementation, similar to the one in Phobos, but not quite the same. It cached the hashes for boosted speed.

In phobos2, the AA implementation is completely different. This first manifested itself as linker errors on foreach statements (fix it by compiling as:

dmd -oftest *.d

instead of using the makefile). Then, I noticed obvious things were failing.

After spending a few hours on it, I decided to just give up and use the above hack. I still don't understand why it is happening that way. (I thought const correctness would be the hard thing, but aside from the two casts, it was fairly easy. The stupid AA has been the real problem!)



But, anyway, it now works on some simple scripts, and the asserts in there all work, so I think it is working correctly.

Now, with it compiling as D2, the next step will be making the wrapper template I mentioned yesterday. I don't have time to do it today though.

On the bright side, I know the code a bit better now than I ever did before, so maybe I can make this template better than I thought! We'll see.

All right, now I'm actually done for the day.

Updated the zip at the link: http://arsdnet.net/dcode/dmdscript_d2.zip

To add a pretty interface (pretty.d). It is incomplete, but works to play with. test.d is an example of how to use it.

	auto se = new ScriptEngine;
	se.addFunction!(fun, "fun");  // adding D functions is just giving
the names. the second arg is required since stringof the alias kept
treating it as a property.....
	se.addFunction!(fun2, "fun2");
	se.compile("function test(a) { println(a); }");
	se.call("test", 40); // and it is almost as easy to call script functions!

When I go back to finish it, I'm thinking I'll add more integration with std.variant and opDispatch, so the D and javascript code basically work the same way.


To do this, I did have to do one change to dmdscript itself: edited dnative.d to add an overload constructor so it can take a delegate as well as a function. That let my template just use a nested function to keep it easy. It might not work properly if the script tries to redefine the function though.

Still, good enough for now. I've been at this for 9 hours! Blown my whole day off.

On 3/30/10, Adam Ruppe <destructionator@gmail.com> wrote:
> On 3/29/10, Robert Clipsham <robert@octarineparrot.com> wrote:
>> I seem to recall it is, and a fairly old D1 at that... You could always update it and send a patch Walter's way, see if he accepts it :)
>
> Walter seems to have fixed it up the the new D1; it compiled there.
>
> And I just spent the day making a port to D2. There's a few WTFs in there though, which I hacked around.
>
> Here it is:
> http://arsdnet.net/dcode/dmdscript_d2.zip
>
> First, once each in dobject.d and script.d, I casted away a const. grep for FIXME.
>
> Second, and this is the big one: the assocative array implementation in there seems to have broken entirely with the switch to D2. Look for "BIG HACK" in property.d - I had to do this two times:
>
> 	assert(key !is null);
> 	p = *key in table;
>
> 	// BIG HACK! in seems broken!
>         if(p is null)
> 	foreach(k,ref v; table) {
> 		if(k.toString() == key.toString()) {
> 			p = &v; // WTF
> 			break;
> 		}
> 	}
>
> Previously, it used a custom AA implementation, similar to the one in Phobos, but not quite the same. It cached the hashes for boosted speed.
>
> In phobos2, the AA implementation is completely different. This first manifested itself as linker errors on foreach statements (fix it by compiling as:
>
> dmd -oftest *.d
>
> instead of using the makefile). Then, I noticed obvious things were failing.
>
> After spending a few hours on it, I decided to just give up and use the above hack. I still don't understand why it is happening that way. (I thought const correctness would be the hard thing, but aside from the two casts, it was fairly easy. The stupid AA has been the real problem!)
>
>
>
> But, anyway, it now works on some simple scripts, and the asserts in there all work, so I think it is working correctly.
>
> Now, with it compiling as D2, the next step will be making the wrapper template I mentioned yesterday. I don't have time to do it today though.
>
> On the bright side, I know the code a bit better now than I ever did before, so maybe I can make this template better than I thought! We'll see.
>

> What I think I'd like in D is something like this, but I think there's no need to use JavaScript for this, it can be used just D code:
> https://developer.mozilla.org/en/Treehydra

This page explains what Treehydra is: https://developer.mozilla.org/En/Treehydra_Manual

>Treehydra is meant to be used for analyses that need more detail than Dehydra's flattened ASTs. Instead of representing code in "easy" form like Dehydra, Treehydra relies on GIMPLE, the GCC Internals "middle-end" intermediate representation.<

This is Dehydra, that's quite simpler to use: https://developer.mozilla.org/en/Dehydra

Dehydra for example allows to add JavaScript callbacks to the compiler: https://developer.mozilla.org/En/Dehydra/Function_Reference
>Callback Functions The following functions may be provided by the analysis script and will be called by Dehydra while compiling. See the Dehydra object reference for details on the available object properties.<

The nicer page about Dehydra can be this one: https://developer.mozilla.org/En/Dehydra/Object_Reference

>Dehydra represents C++ types and variables as JavaScript objects. The objects are designed to distill that type system to the minimum such that it can be easy to match on.<

All those properties are present for all the variables, functions, etc, of the C++ code. Such static reflexivity can be useful in D too, to extend the type system a little, for user-defined properties, as a starting point to implement macros.

Bye,
bearophile

On Wed, Mar 31, 2010 at 02:34, Adam Ruppe <destructionator@gmail.com> wrote:

> All right, now I'm actually done for the day.
>
> Updated the zip at the link: http://arsdnet.net/dcode/dmdscript_d2.zip
>
>        se.addFunction!(fun, "fun");  // adding D functions is just giving
> the names. the second arg is required since stringof the alias kept
> treating it as a property.....
>

I remember having the same problem... You can try  __traits(identifier,
...):

enum string  scriptName = getPlainName!(__traits(identifier, T));


Philippe

On Wed, Mar 31, 2010 at 08:06:11PM +0200, Philippe Sigaud wrote:
> enum string  scriptName = getPlainName!(__traits(identifier, T));

Outstanding! That did it.

I'll update the zip on my website at the end of the day. I now have wrapping of exceptions from script/native set up too. When I have the time I'm thinking about making a wrapper with opdispatch and std.variant to try and erase the lines between script world and native world.

-- 
Adam D. Ruppe
http://arsdnet.net

On Wed, Mar 31, 2010 at 20:22, Adam D. Ruppe <destructionator@gmail.com>wrote:

> On Wed, Mar 31, 2010 at 08:06:11PM +0200, Philippe Sigaud wrote:
> > enum string  scriptName = getPlainName!(__traits(identifier, T));
>
> Outstanding! That did it.
>
> Cool, I wasn't sure it'd work. Now we know what this new trait is for :)

On Wed, Mar 31, 2010 at 09:03:10PM +0200, Philippe Sigaud wrote:
> Cool, I wasn't sure it'd work. Now we know what this new trait is for :)

It is slightly different than my old code: the getPlainName helper function is not required with the __trait. (It truncated the string at the first paren, since stringof returns the arguments too, whereas identifier does not).

I think it would be a good idea to get a nice overview doc written up on template idioms - things like this, how to use the isSomeString, etc, templates in std.traits to work the constraints, and so on.

Another one in pretty.d I hit was taking a ParameterTypeTuple and using it to expand the runtime args array. At first, I used a list of static if T.length == 1, and manually written it out. Today, I changed it to a CTFE function returning a string to mix on, which sucks less, but still feels weird.

Having a nice overview document would be good to save time and make this kind of code prettier. Maybe I'll write one to get started then post it to the group for additions and improvements. Don't have the time today though.

-- 
Adam D. Ruppe
http://arsdnet.net

On Wed, Mar 31, 2010 at 21:21, Adam D. Ruppe <destructionator@gmail.com>wrote:

> On Wed, Mar 31, 2010 at 09:03:10PM +0200, Philippe Sigaud wrote:
> > Cool, I wasn't sure it'd work. Now we know what this new trait is for :)
>
> It is slightly different than my old code: the getPlainName helper function is not required with the __trait. (It truncated the string at the first paren, since stringof returns the arguments too, whereas identifier does not).
>

I get it.


>
> I think it would be a good idea to get a nice overview doc written up on template idioms - things like this, how to use the isSomeString, etc, templates in std.traits to work the constraints, and so on.
>

Or the way to sneak arrays as template parameters...

Oh yes. I'd be willing to participate, but I'm also waiting to see what Andrei says in his book.

I recently made a template to bind template parameters, and another to
determine the 'arity' of a template (no param, 1, etc.). The latter was
after discovering that if an alias parameter is a template, the .stringof
gives the entire signature : parameters, constraints, etc.
I'm discovering something new every week and I have the impression my
knowledge of templates is ... kaleidoscopic : lots of colorful parts, no
global vision.



> Another one in pretty.d I hit was taking a ParameterTypeTuple and using it to expand the runtime args array. At first, I used a list of static if T.length == 1, and manually written it out. Today, I changed it to a CTFE function returning a string to mix on, which sucks less, but still feels weird.
>

I still feel wrong when I'm using CTFE. That's too bad, because with the recent leaps in the CTFE perimeter Don made, CTFE has become a very powerful tool indeed.


Having a nice overview document would be good to save time and make this
> kind of code prettier. Maybe I'll write one to get started then post it to the group for additions and improvements. Don't have the time today though.
>

A document, or a wiki page. But to start things and get a little attention, a discussion here is better.


  Philippe