what prevents dynamic array from being deprecated & tuple being accepted?

davidl davidl at 126.com
Thu Apr 2 02:09:01 PDT 2009


在 Thu, 02 Apr 2009 12:08:39 +0800,davidl <davidl at 126.com> 写道:

> Something like following can substitute dynamic array:
> struct da(T){
>      T* ptr;
>      int len, capacity;
>      T opIndex(int i){}
>      int length(){ return len;}
>      void length(int len){ // do allocation}
>      this(int i){ //allocate memory for ptr }
>      this(){ // do nothing}
>      da!(T) opCat(T* a){ //do concat }
>      da!(T) opCat_r(T* a){ //do concat }
>      da!(T) opCat(T c){ //do concat }
>      da!(T) opCat_r(T c){ //do concat }
>      opAssign(T* p) {}
>      opAssign(da!(T) da) {}
>      da!(T) opMul(int i) {}
>      da!(T) opMul(da!(T) i) {}  // some dot product ?
>      da!(T) opDiv(da!(T) i) {}
> }
>
> auto myda = da!(int)(3)
> auto p = da!(int)();
>
> p = myda~3;
>
>
> The cons/pros of this proposal:
> Cons:
> ungly syntax   da!(int)(3) is really worse than int[3];
> slow down the compiling process
>
> Pros:
> We can extend dynamic array without D2 feature of alias This
>
> Also Tuple!(int, float) is accused as ugly
>
> I believe the metatype programming system here not yet fully exploited.
>
> The template matching is powerful, but the syntax is aweful.
>
> how about the following beautify of da!(int)(3) and tuple!(int,float)
>
> type(T)  // overload all types
> {
>     opIndex(int v)
>     {
>         type = da!(T)(v)   // we directly meta program the type system
>     }
>     opIndex(U)
>     {
>         // associate array, assume we created some associate array  
> struct template named Aa
>         type = Aa!(U, T)
>     }
>     opCat(U)
>     {
>         type = Tuple!(T,U);
>     }
> }
>
> then we can do :
>
> int[3] => type(int) opIndex(int v) then further resolve the type to be  
> da!(int)(3)
>
> int~float => type(int) opCat(float) , therefore further resolve the type  
> to be Tuple!(int, float)
>
> I think tuple of int~float is quite acceptable
>
> With this directly metaprogramming, we can solve series of issues all  
> together.
>
>
> We can define a matrix by int^int or float^float
>
> Imagine:
>
> int^int mat= new int^int(3,4);
> int[4] p;
> auto v= mat*p;   // we can do a lot compile time check in the  
> compiletime type syntax meta programming
>
>
> We can define function curry as:
> f^g h;
> h(3) will eventually become f(g(3));
>
>
> We can do a lot more new things!! :)
>

the curry example needs symbol level operator overloading.

type overloading can allow:

-int  <-- which might be overloaded to type of anything without int.

int[int~int] thus mean two dimensional associate array.
int[int~float] p;
p[3~2.5]= 3;

In all, this makes a lot of things with much better syntax.




More information about the Digitalmars-d mailing list