Proposal: Alias more powerful concurrency, and more powerful manipulation of try block

[DavidL]

Consider the following:
here I propose two syntax, firstly scope(char[] ScopeName){} ,this syntax  
name those unnamed scope,
and it also make alias for named scope.

void func(){} <-- this a named scope
for(;;){}  <-- here is a anonymous scope

scope("myscope"){ void func(){} } <--- we set up an alias "myscope" for  
func
scope("forscope"){for(;;){}}  <--- we name the anonymous scope with  
scope("forscope")
for(;;)scope("forscope"){} should do exactly the same as  
scope("forscope"){for(;;){}}

ok, now we come to the second syntax proposal.
void func()
{
    int symbol;
}
void anotherfunc()
{
    alias func.symbol localsymbol;  // here i tend to introduce the symbol  
for local stack simulation for concurrency manipulation.
}


a little bit more complicated situation

void func()
{
   int symbol;
   for(int i;i<200;i++) scope("myscope"){

   }
}

void anotherfunc()
{
   alias func.myscope.i funci; //  now if we get the same EBP of execution  
of func, the compiler would ensure us the &func.myscope.i should be the  
same as &funci. If func.myscope.i is optimized to registers, the compiler  
would ensure funci also access the value through the register which  
func.myscope.i use.
}


Let's go a little bit further and concern the parameters of a func :

void func(int fancyarg, ...)
{

}

void anotherfunc()
{
   alias func.fancyarg funcparam;
   alias func.__parameter funcelipsisparams;

}

Ok , what's the motivation of proposing such a feature?

consider cheap concurrency:

void func()
{
   int i;
   int j;
   //library yield func
}

the yield is fine, but we lose the opportunity of interacting with func

and consider a classical situation of a signal and handling.
Windows SEH specific(though I think this could also be done on Linux):

char globalchar;
int FilterFunc()
{
   alias func1.flag flag;
   alias func1.p p;
   // i emit the code of making the context the same as func1. The SEH can  
provide us the exact the same context with fucn1
   if (flag>2) // we can do some fancy operation , the code here just mean  
to illustrate the manipulation of the context of func
   {
     return EXCEPTION_EXECUTE_HANDLER;  // really handle the exception in  
our handler block.
   }
   else
   {
     p= &globalchar;
     // call some signal handle func
     return EXCEPTION_CONTINUE_EXECUTION;  // we can continue the execution  
of func , with *p points to globalchar
   }

}

void func()
{
   __try         // original SEH try
   {
     func1;
   }
   // i hope if D could expose some kind of this low level exception  
manipulation to us.
   __ecept(FilterFunc)  //original SEH catch block with calling to filter  
func firstly to determine what to do with the exception.
   {
      // we only come to here with func1.flag > 2

   }
}

void func1()
{
   int flag;
   char *p=cast(char*)0;
   *p=0;			// trigger the exception. The filter func gets run. now we get p  
points to globalchar
   assert(p !is null);
   flag=3;
   p=cast(char*)0;
   *p=0;                 // trigger the exception. The filter func gets  
run. Now the exception really get thrown to the func. func handler gets run
}

The above is useful for creating some complicated obfuscating code of  
preventing someone from debugging :D
Though it's a nice try to give an alternative of current signal & slot by  
using exceptions.









-- 
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/