A couple of people have been asking questions about pseudo-real-life examples for the new compile time code aspects of D.  I ask this question for my interest as well.

Assuming that we have a good mechanism to process the input how could compile time code improve your every-day proficiency?  (This is specifically about the Mixin Expressions aspect).

I'll start with a few of my own.  Note my background is
game-programming.  In my experience, we care constantly creating tools to generate code because its impracticable to write and maintain it by hand.

Statemachine (and AI logic) written by design and coders are common in game programming.  Normally we have to fallback on a script language which is never as powerful.

mixin(statemachine(
"
	state FireAtEnemy
	{
		transition EnemyRange < 10
		{
			goto ChaseEnemy
		}
		transition FacingEnemy < .2
		{
			goto ChaseEnemy
		}
	}

	state ChaseEnemy
	{
		...
	}

");

You might imagine doing the above with if statement and arrays of delegates however designers have a much harder time with that.

3D Object rendering

//Render a 3D model.  For instance this may generate the vertexbuffers and textures directly into code, or may extract some of the data from the 3Dmodel.obj and load the rest at run-time.
mixin(renderModel(import("3Dmodel.obj")));

Transforming Textures
DXDtexture* texture = mixin(textureToD3D(import("3Dmodel.bmp")));

Simplify saving/loading of arbitrary structures.

//Only write this once.  Things are re-ordered for best fit in memory, localization ect...
mixin(Serailzable("Ship",
"
	struct Part
	{
		float firePower;
		char[] Model;
	}

	struct Ship
	{
		bool Friendly;
		Part Parts[];
	}
");

... Later

Load("Ship", "Ship.asset");

GUI -> not sure about this one as I can't come up with a format thats much neater then straight code. I'll post it anyways.

mixin(MyGUI(
"
	Button "OK", 10, 30
	{
		Exit;
	}
");

Multi-threading

The suggestion with multi-threading I came up with a little while ago:

int[] array ...
int result = 0;
mixin(threadIt(
"
	foreach(A a; array)
	{
		result += a;
	}
	combiner //If necessary?
	{
		result = result[0] + result[1];
	}
");

Compile time checking of code for coding standards or what have u:

mixin(CheckCode("

ect...


");
//Note that there should be a way to disable CheckCode in the general case to save compile time


There's heaps of other stuff, but that would make this post way to long.

Personally I see this new mixin format as giving us the power to extend D in whatever way meets our goals.  As Walter adds more features some of them will be rarely used (law of demising returns) because they are special case.  Mixin Expressions circumvent this because now the programmer has the power to create the language features they need.

The only downside I see is compile-time, which I hope can be solved with a smart caching system.

janderson wrote:
> A couple of people have been asking questions about pseudo-real-life examples for the new compile time code aspects of D.  I ask this question for my interest as well.
> 
> Assuming that we have a good mechanism to process the input how could compile time code improve your every-day proficiency?  (This is specifically about the Mixin Expressions aspect).
> 
> I'll start with a few of my own.  Note my background is
> game-programming.  In my experience, we care constantly creating tools to generate code because its impracticable to write and maintain it by hand.
> 
> Statemachine (and AI logic) written by design and coders are common in game programming.  Normally we have to fallback on a script language which is never as powerful.
> 
> mixin(statemachine(
> "
>     state FireAtEnemy
>     {
>         transition EnemyRange < 10
>         {
>             goto ChaseEnemy
>         }
>         transition FacingEnemy < .2
>         {
>             goto ChaseEnemy
>         }
>     }
> 
>     state ChaseEnemy
>     {
>         ...
>     }
> 
> ");
> 
> You might imagine doing the above with if statement and arrays of delegates however designers have a much harder time with that.
> 
> 3D Object rendering
> 
> //Render a 3D model.  For instance this may generate the vertexbuffers and textures directly into code, or may extract some of the data from the 3Dmodel.obj and load the rest at run-time.
> mixin(renderModel(import("3Dmodel.obj")));
> 
> Transforming Textures
> DXDtexture* texture = mixin(textureToD3D(import("3Dmodel.bmp")));
> 
> Simplify saving/loading of arbitrary structures.
> 
> //Only write this once.  Things are re-ordered for best fit in memory, localization ect...
> mixin(Serailzable("Ship",
> "
>     struct Part
>     {
>         float firePower;
>         char[] Model;
>     }
> 
>     struct Ship
>     {
>         bool Friendly;
>         Part Parts[];
>     }
> ");
> 
> ... Later
> 
> Load("Ship", "Ship.asset");
> 
> GUI -> not sure about this one as I can't come up with a format thats much neater then straight code. I'll post it anyways.
> 
> mixin(MyGUI(
> "
>     Button "OK", 10, 30
>     {
>         Exit;
>     }
> ");
> 
> Multi-threading
> 
> The suggestion with multi-threading I came up with a little while ago:
> 
> int[] array ...
> int result = 0;
> mixin(threadIt(
> "
>     foreach(A a; array)
>     {
>         result += a;
>     }
>     combiner //If necessary?
>     {
>         result = result[0] + result[1];
>     }
> ");
> 
> Compile time checking of code for coding standards or what have u:
> 
> mixin(CheckCode("
> 
> ect...
> 
> 
> ");
> //Note that there should be a way to disable CheckCode in the general case to save compile time
> 
> 
> There's heaps of other stuff, but that would make this post way to long.
> 
> Personally I see this new mixin format as giving us the power to extend D in whatever way meets our goals.  As Walter adds more features some of them will be rarely used (law of demising returns) because they are special case.  Mixin Expressions circumvent this because now the programmer has the power to create the language features they need.
> 
> The only downside I see is compile-time, which I hope can be solved with a smart caching system.


Thanks, very much. It's refreshing to see some concrete examples.

- Kris

janderson wrote:
> 
> Simplify saving/loading of arbitrary structures.
> 
> //Only write this once.  Things are re-ordered for best fit in memory, localization ect...
> mixin(Serailzable("Ship",
> "
>     struct Part
>     {
>         float firePower;
>         char[] Model;
>     }
> 
>     struct Ship
>     {
>         bool Friendly;
>         Part Parts[];
>     }
> ");
> 
> ... Later
> 

I wrote this up pretty fast, you probably got the point.  However:

> Load("Ship", "Ship.asset");
>

would probably look more like:

Ship ship;
Load(ship, "Ship.asset");
...
Save(ship, "Ship.asset");

-Joel

janderson wrote:
> 
> Personally I see this new mixin format as giving us the power to extend D in whatever way meets our goals.  As Walter adds more features some of them will be rarely used (law of demising returns) because they are special case.  Mixin Expressions circumvent this because now the programmer has the power to create the language features they need.
> 
> The only downside I see is compile-time, which I hope can be solved with a smart caching system.


I would also like to add:  Mixin Expressions allow us to experiment with new features for the D language.

Over the course of time we may discover some privative building blocks that are very useful.  Hopefully they would eventually make themselves into the core of the language.

-Joel

janderson wrote:
> A couple of people have been asking questions about pseudo-real-life examples for the new compile time code aspects of D.  I ask this question for my interest as well.
> 
> Assuming that we have a good mechanism to process the input how could compile time code improve your every-day proficiency?  (This is specifically about the Mixin Expressions aspect).
> 
> I'll start with a few of my own.  Note my background is
> game-programming.  In my experience, we care constantly creating tools to generate code because its impracticable to write and maintain it by hand.
> 
> Statemachine (and AI logic) written by design and coders are common in game programming.  Normally we have to fallback on a script language which is never as powerful.
> 
> mixin(statemachine(
> "
>     state FireAtEnemy
>     {
>         transition EnemyRange < 10
>         {
>             goto ChaseEnemy
>         }
>         transition FacingEnemy < .2
>         {
>             goto ChaseEnemy
>         }
>     }
> 
>     state ChaseEnemy
>     {
>         ...
>     }
> 
> ");
> 
> You might imagine doing the above with if statement and arrays of delegates however designers have a much harder time with that.

This example is eerily on target. A while ago I've enjoyed watching a talk by Shriram Khrishnamurthi on... you gotta see it:

http://technetcast.ddj.com/tnc_play_stream.html?stream_id=644

Unfortunately, it looks like DDJ does not have the audio (which was fantastic) anymore, so you can only see the slides (which are very good as well). The slides 37 to 39 knocked my socks off so hard they stuck onto the wall, and to this day I couldn't peel them away.

The way I'm seeing defining such DSLs is a bit more conservative than yours: I'd let the D compiler do most of the parsing and I'd focus on defining the state transitions:

class GameEngine
{
  mixin automaton!(
    State!(FireAtEnemy,
      ("EnemyRange < 10", "ChaseEnemy"),
      ("FacingEnemy < .2", "ChaseEnemy")),
    State!(ChaseEnemy,
      ...)
  )
}

It's amazing to think that D will allow this (actually already allows with a slightly clunkier syntax). I'll make sure I'll be barefoot that day. :o)

> 3D Object rendering
> 
> //Render a 3D model.  For instance this may generate the vertexbuffers and textures directly into code, or may extract some of the data from the 3Dmodel.obj and load the rest at run-time.
> mixin(renderModel(import("3Dmodel.obj")));
> 
> Transforming Textures
> DXDtexture* texture = mixin(textureToD3D(import("3Dmodel.bmp")));

Sounds great, but no expertise to comment on that.

> Simplify saving/loading of arbitrary structures.
> 
> //Only write this once.  Things are re-ordered for best fit in memory, localization ect...
> mixin(Serailzable("Ship",
> "
>     struct Part
>     {
>         float firePower;
>         char[] Model;
>     }
> 
>     struct Ship
>     {
>         bool Friendly;
>         Part Parts[];
>     }
> ");
> 
> ... Later
> 
> Load("Ship", "Ship.asset");

Yah, this has been pointed out indeed. Also add remote procedure calls. Generating all of the marshaling/unmarshaling code (for various standards!) will be trivially done by libraries. I actually see PyD as a great first application of that concept that will spark many others.

> GUI -> not sure about this one as I can't come up with a format thats much neater then straight code. I'll post it anyways.
> 
> mixin(MyGUI(
> "
>     Button "OK", 10, 30
>     {
>         Exit;
>     }
> ");

Great. The problem with GUI programming has always been that programming language is not a natural vehicle for specifying forms and stuff. Many frameworks have relied on some framework for code generation and impedance matching (Tcl/Tk, Windows resources, ...) with various levels of awkwardness. Due to its compile-time manipulation abilities, D will make it trivial to bind GUI resources to D code.

The way I see this happening is more along the lines:

mixin(import "inputform.rc")

The file can be generated and edited with other tools (e.g. gui designers). That's why I insisted with Walter that strings should be importable from files. This effectively makes you benefit of the dual cake paradox, in that at the same time you have the advantage of separate files for separate languages, and the advantage of seamless integration between them.

> Multi-threading
> 
> The suggestion with multi-threading I came up with a little while ago:
> 
> int[] array ...
> int result = 0;
> mixin(threadIt(
> "
>     foreach(A a; array)
>     {
>         result += a;
>     }
>     combiner //If necessary?
>     {
>         result = result[0] + result[1];
>     }
> ");
> 
> Compile time checking of code for coding standards or what have u:

I'm not understanding this.

> mixin(CheckCode("
> 
> ect...
> 
> 
> ");
> //Note that there should be a way to disable CheckCode in the general case to save compile time

I guess this is an obvious:

mixin(CheckCode(import "program.d"));

A file containing a mixin for each program in a project can be generated by the build process.

> There's heaps of other stuff, but that would make this post way to long.

There's always the opportunity of a next post :o).

> Personally I see this new mixin format as giving us the power to extend D in whatever way meets our goals.  As Walter adds more features some of them will be rarely used (law of demising returns) because they are special case.  Mixin Expressions circumvent this because now the programmer has the power to create the language features they need.

Yah indeed. This has been a source of disagreement in the past between Walter and myself. He used to favor compiler-wired features, while I envisioned an infinitely configurable language with an exceedingly small core. Time has past, and we both learned some of the advantages of the other's approach.

> The only downside I see is compile-time, which I hope can be solved with a smart caching system.

Stay tuned. Compilation times will come down dramatically. Walter is up to something pretty cool, but it will take a while. Advice: don't wear socks when reading d.announce :o).


Andrei

kris wrote:
> janderson wrote:
>> A couple of people have been asking questions about pseudo-real-life examples for the new compile time code aspects of D.  I ask this question for my interest as well.
>>
>> Assuming that we have a good mechanism to process the input how could compile time code improve your every-day proficiency?  (This is specifically about the Mixin Expressions aspect).
>>
>> I'll start with a few of my own.  Note my background is
>> game-programming.  In my experience, we care constantly creating tools to generate code because its impracticable to write and maintain it by hand.
>>
>> Statemachine (and AI logic) written by design and coders are common in game programming.  Normally we have to fallback on a script language which is never as powerful.
>>
>> mixin(statemachine(
>> "
>>     state FireAtEnemy
>>     {
>>         transition EnemyRange < 10
>>         {
>>             goto ChaseEnemy
>>         }
>>         transition FacingEnemy < .2
>>         {
>>             goto ChaseEnemy
>>         }
>>     }
>>
>>     state ChaseEnemy
>>     {
>>         ...
>>     }
>>
>> ");
>>
>> You might imagine doing the above with if statement and arrays of delegates however designers have a much harder time with that.
>>
>> 3D Object rendering
>>
>> //Render a 3D model.  For instance this may generate the vertexbuffers and textures directly into code, or may extract some of the data from the 3Dmodel.obj and load the rest at run-time.
>> mixin(renderModel(import("3Dmodel.obj")));
>>
>> Transforming Textures
>> DXDtexture* texture = mixin(textureToD3D(import("3Dmodel.bmp")));
>>
>> Simplify saving/loading of arbitrary structures.
>>
>> //Only write this once.  Things are re-ordered for best fit in memory, localization ect...
>> mixin(Serailzable("Ship",
>> "
>>     struct Part
>>     {
>>         float firePower;
>>         char[] Model;
>>     }
>>
>>     struct Ship
>>     {
>>         bool Friendly;
>>         Part Parts[];
>>     }
>> ");
>>
>> ... Later
>>
>> Load("Ship", "Ship.asset");
>>
>> GUI -> not sure about this one as I can't come up with a format thats much neater then straight code. I'll post it anyways.
>>
>> mixin(MyGUI(
>> "
>>     Button "OK", 10, 30
>>     {
>>         Exit;
>>     }
>> ");
>>
>> Multi-threading
>>
>> The suggestion with multi-threading I came up with a little while ago:
>>
>> int[] array ...
>> int result = 0;
>> mixin(threadIt(
>> "
>>     foreach(A a; array)
>>     {
>>         result += a;
>>     }
>>     combiner //If necessary?
>>     {
>>         result = result[0] + result[1];
>>     }
>> ");
>>
>> Compile time checking of code for coding standards or what have u:
>>
>> mixin(CheckCode("
>>
>> ect...
>>
>>
>> ");
>> //Note that there should be a way to disable CheckCode in the general case to save compile time

Hmm.  Me hopes more and more that something can be done about string literals.  I don't really want to end up having big chunks of my code stashed away in quotes.  Editors don't know how to highlight it or format it, even if it's plain D on the inside.

>> There's heaps of other stuff, but that would make this post way to long.
>>
>> Personally I see this new mixin format as giving us the power to extend D in whatever way meets our goals.  As Walter adds more features some of them will be rarely used (law of demising returns) because they are special case.  Mixin Expressions circumvent this because now the programmer has the power to create the language features they need.
>>
>> The only downside I see is compile-time, which I hope can be solved with a smart caching system.
> 
> 
> Thanks, very much. It's refreshing to see some concrete examples.
> 

I had forgotten about this, but there's also the example of Qt's dynamic signals and slots that was discussed a while back.  Qt's moc compiler /sort of/ knows how to process most /garden-variety/ C++ in order to extract method signatures, so that it can generate string-based run-time stubs.  The stubs let you write code like:
    connect(object1,"notifyFoo(int)", object2,"fooChanged(int)");
To connect up object1's notifyFoo signal with object2's fooChanged method.  In Qt's implementation, the moc compiler generates a string->method_pointer lookup table in each QObject and some other boilerplate so that the lookup can be done dynamically at runtime.  That allows you to load a UI script at runtime and connect up the signals and slots dynamically based on just the names of methods.

Actually, that seems like it should be mostly doable already via tuples and mixins.  But instead of syntax like
    slot void myMethod(int x) { . . . }
you'd need
    void myMethod(int x) { . . . }
    mixin DynamicSlot!("myMethod");

But you'd probably need to declare all the dynamic slots in one place, like
    mixin DynamicSlots!("myMethod",
			"myOtherMethod",
			"aThirdMethod");
It would be nice if you could do them a method at a time, though, to keep them close to the place where they're declared.  Even better if it could be done without repeating the name.   Maybe something like

    mixin(DynamicSlot!("void myMethod(int x)")) { . . . }

Meh.  Still ugly.  It would be a lot nicer if it could just be
    DynamicSlot! void myMethod(int x) { . . . }

Still not sure how that would manage to collect all the slot info into one big function that does the run-time lookup, though.

--bb

Andrei Alexandrescu (See Website For Email) wrote:
> janderson wrote:
>> mixin(statemachine(
>> "
>>     state FireAtEnemy
>>     {
>>         transition EnemyRange < 10
>>         {
>>             goto ChaseEnemy
>>         }
>>         transition FacingEnemy < .2
>>         {
>>             goto ChaseEnemy
>>         }
>>     }
>>
>>     state ChaseEnemy
>>     {
>>         ...
>>     }
>>
>> ");
>>
>> You might imagine doing the above with if statement and arrays of delegates however designers have a much harder time with that.
> 
> This example is eerily on target. A while ago I've enjoyed watching a talk by Shriram Khrishnamurthi on... you gotta see it:
> 
> http://technetcast.ddj.com/tnc_play_stream.html?stream_id=644
> 
> Unfortunately, it looks like DDJ does not have the audio (which was fantastic) anymore, so you can only see the slides (which are very good as well). The slides 37 to 39 knocked my socks off so hard they stuck onto the wall, and to this day I couldn't peel them away.
> 
> The way I'm seeing defining such DSLs is a bit more conservative than yours: I'd let the D compiler do most of the parsing and I'd focus on defining the state transitions:

Actually its very similar to a format that I've used in past games (except was a run-time thing).

> 
> class GameEngine
> {
>   mixin automaton!(
>     State!(FireAtEnemy,
>       ("EnemyRange < 10", "ChaseEnemy"),
>       ("FacingEnemy < .2", "ChaseEnemy")),
>     State!(ChaseEnemy,
>       ...)
>   )
> }


The difficulty with this approach is that its much harder to read and write, of course.  Also its harder to do global optimizations. Furthermore you can't type straight D code into it.  I'm seeing the statemachine as converting any code it doesn't understand into D code so you can use the power of D (for instance, you don't have to define operators for maths operations, you'd still be able to user for loops.).

Its seems like your trying to design around the limitations of the compiler.

Here's a version with mixed-in-D-Code.

mixin(statemachine(

import("Standard.behaviors") ~ //You could even reuse states like this
 "

     state FireAtEnemy
     {
         transition Me.DistanceToEnemy > 10 && Me.DistanceToEnemy < 20
         {
             goto ChaseEnemy
         }
         transition Me.FacingEnemy < .2
         {
             goto ChaseEnemy
         }
     }

     state ChaseEnemy
     {
        auto Direction = Enermy.Pos - Me.Pos;
	Me.SetFacing(Direction);

	if (EnemyRange > 20)
	{
		Me.Run();
	}
	else if (EnemyRange > 10)
	{
		Me.Walk();
	}
	else
	{
		Me.Stop();
		goto FireAtEnemy;
	}
     }

 ");

Note much of the time this would be done with an import.


> 
> It's amazing to think that D will allow this (actually already allows with a slightly clunkier syntax). I'll make sure I'll be barefoot that day. :o)
> 
>> 3D Object rendering
>>
>> //Render a 3D model.  For instance this may generate the vertexbuffers and textures directly into code, or may extract some of the data from the 3Dmodel.obj and load the rest at run-time.
>> mixin(renderModel(import("3Dmodel.obj")));
>>
>> Transforming Textures
>> DXDtexture* texture = mixin(textureToD3D(import("3Dmodel.bmp")));
> 
> Sounds great, but no expertise to comment on that.
> 
>> Simplify saving/loading of arbitrary structures.
>>
>> //Only write this once.  Things are re-ordered for best fit in memory, localization ect...
>> mixin(Serailzable("Ship",
>> "
>>     struct Part
>>     {
>>         float firePower;
>>         char[] Model;
>>     }
>>
>>     struct Ship
>>     {
>>         bool Friendly;
>>         Part Parts[];
>>     }
>> ");
>>
>> ... Later
>>
>> Load("Ship", "Ship.asset");
> 
> Yah, this has been pointed out indeed. Also add remote procedure calls. Generating all of the marshaling/unmarshaling code (for various standards!) will be trivially done by libraries. I actually see PyD as a great first application of that concept that will spark many others.
> 
>> GUI -> not sure about this one as I can't come up with a format thats much neater then straight code. I'll post it anyways.
>>
>> mixin(MyGUI(
>> "
>>     Button "OK", 10, 30
>>     {
>>         Exit;
>>     }
>> ");
> 
> Great. The problem with GUI programming has always been that programming language is not a natural vehicle for specifying forms and stuff. Many frameworks have relied on some framework for code generation and impedance matching (Tcl/Tk, Windows resources, ...) with various levels of awkwardness. Due to its compile-time manipulation abilities, D will make it trivial to bind GUI resources to D code.
> 
> The way I see this happening is more along the lines:
> 
> mixin(import "inputform.rc")
> 

I see both.  You can enter it directly when you want to do a little bit of code or proto-typing, and use import when u need that.

> The file can be generated and edited with other tools (e.g. gui designers). That's why I insisted with Walter that strings should be importable from files. This effectively makes you benefit of the dual cake paradox, in that at the same time you have the advantage of separate files for separate languages, and the advantage of seamless integration between them.
> 
>> Multi-threading
>>
>> The suggestion with multi-threading I came up with a little while ago:
>>
>> int[] array ...
>> int result = 0;
>> mixin(threadIt(
>> "
>>     foreach(A a; array)
>>     {
>>         result += a;
>>     }
>>     combiner //If necessary?
>>     {
>>         result = result[0] + result[1];
>>     }
>> ");
>>
>> Compile time checking of code for coding standards or what have u:
> 
> I'm not understanding this.

What part?

> 
>> mixin(CheckCode("
>>
>> ect...
>>
>>
>> ");
>> //Note that there should be a way to disable CheckCode in the general case to save compile time
> 
> I guess this is an obvious:
> 
> mixin(CheckCode(import "program.d"));

Exactly, both would be supported.  Sometimes its useful to have code in the same context that its been used.  Sometimes not.

> 
> A file containing a mixin for each program in a project can be generated by the build process.
> 
>> There's heaps of other stuff, but that would make this post way to long.
> 
> There's always the opportunity of a next post :o).

Actually, the real reason is I'm just lazy.

> 
> Stay tuned. Compilation times will come down dramatically. Walter is up to something pretty cool, but it will take a while. 

This is great news

> Advice: don't wear socks when reading d.announce :o).

I'm taking them off now.

> 
> Andrei

Bill Baxter wrote:
> 
> Hmm.  Me hopes more and more that something can be done about string literals.  I don't really want to end up having big chunks of my code stashed away in quotes.  Editors don't know how to highlight it or format it, even if it's plain D on the inside.

You can always use import.


> 
> I had forgotten about this, but there's also the example of Qt's dynamic signals and slots that was discussed a while back.  Qt's moc compiler /sort of/ knows how to process most /garden-variety/ C++ in order to extract method signatures, so that it can generate string-based run-time stubs.  The stubs let you write code like:
>     connect(object1,"notifyFoo(int)", object2,"fooChanged(int)");
> To connect up object1's notifyFoo signal with object2's fooChanged method.  In Qt's implementation, the moc compiler generates a string->method_pointer lookup table in each QObject and some other boilerplate so that the lookup can be done dynamically at runtime.  That allows you to load a UI script at runtime and connect up the signals and slots dynamically based on just the names of methods.
> 
> Actually, that seems like it should be mostly doable already via tuples and mixins.  But instead of syntax like
>     slot void myMethod(int x) { . . . }
> you'd need
>     void myMethod(int x) { . . . }
>     mixin DynamicSlot!("myMethod");
> 
> But you'd probably need to declare all the dynamic slots in one place, like
>     mixin DynamicSlots!("myMethod",
>             "myOtherMethod",
>             "aThirdMethod");
> It would be nice if you could do them a method at a time, though, to keep them close to the place where they're declared.  Even better if it could be done without repeating the name.   Maybe something like
> 
>     mixin(DynamicSlot!("void myMethod(int x)")) { . . . }
> 
> Meh.  Still ugly.  It would be a lot nicer if it could just be
>     DynamicSlot! void myMethod(int x) { . . . }

Your right, I was wondering if the mixin format itself could some how be improved.  Although its a good way of indicating, user-specified code goes here.  Of course you could do something like:

mixin(DynamicSlot!("

void myMothod(int x)
{
 ...
}

"));

or defined you own language extensions:

mixin(MyLanguageExtentions!(import(foo.d));

//foo.d
DynamicSlot! void myMothod(int x)
{
 ...
}

ect...

However I'm guessing the overhead could become insane, particularly when people start writing:

mixin(BobsLanguageExtentions!(MyLanguageExtentions!(import(foo.d))));

Maybe if you could somehow have an efficient tokenisor and mix bobs and your language extensions together in one template it may be adequate. The time you save with the language extensions may offset the time used to compile the code.

> 
> Still not sure how that would manage to collect all the slot info into one big function that does the run-time lookup, though.


> 
> --bb

janderson wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> janderson wrote:
>>> Multi-threading
>>>
>>> The suggestion with multi-threading I came up with a little while ago:
>>>
>>> int[] array ...
>>> int result = 0;
>>> mixin(threadIt(
>>> "
>>>     foreach(A a; array)
>>>     {
>>>         result += a;
>>>     }
>>>     combiner //If necessary?
>>>     {
>>>         result = result[0] + result[1];
>>>     }
>>> ");
>>>
>>> Compile time checking of code for coding standards or what have u:
>>
>> I'm not understanding this.
> 
> What part?

The multi-threading part.

Andrei

Andrei Alexandrescu (See Website For Email) wrote:
> janderson wrote:
>> Andrei Alexandrescu (See Website For Email) wrote:
>>> janderson wrote:
>>>> Multi-threading
>>>>
>>>> The suggestion with multi-threading I came up with a little while ago:
>>>>
>>>> int[] array ...
>>>> int result = 0;
>>>> mixin(threadIt(
>>>> "
>>>>     foreach(A a; array)
>>>>     {
>>>>         result += a;
>>>>     }
>>>>     combiner //If necessary?
>>>>     {
>>>>         result = result[0] + result[1];
>>>>     }
>>>> ");
>>>>
>>>> Compile time checking of code for coding standards or what have u:
>>>
>>> I'm not understanding this.
>>
>> What part?
> 
> The multi-threading part.

Essentially the code would be-reformated to take advantage of multi-cpus.  The code generator threadIt would make a copy of all variables used inside of the foreach and run a partial foreach on each thread.  The combiner bit is run on each thread until they all collapse together (
ie  in this case
resultA = resultofThreadA + resultofThreadB;
resultB = resultofThreadC + resultofThreadD;
result = resultA + resultB; //Final result
)

Of course it goes without saying that each iteration in for for-each must be independent of one another (to some extent).  The advantage being, you see a foreach, and you can just wrap it in "mixin(threadIt(" to get a performance boost.  Looking though some of my C++ code, I'd say 30% of those loops could be mutli-threaded with very little (if any) changes with the above approach.

The basic thought is that you could prove ideas work before even sending a message to the newsgroup.

> 
> Andrei