www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - what prevents dynamic array from being deprecated & tuple being

reply davidl <davidl 126.com> writes:
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!! :)
Apr 01 2009
next sibling parent davidl <davidl 126.com> writes:
在 Thu, 02 Apr 2009 12:08:39 +0800,davidl <davidl 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.
Apr 02 2009
prev sibling parent Trass3r <mrmocool gmx.de> writes:
davidl schrieb:
 The cons/pros of this proposal:
 Cons:
 ungly syntax   da!(int)(3) is really worse than int[3];
 slow down the compiling process
 

Yep, you say it.
 Also Tuple!(int, float) is accused as ugly
 

Can't understand what's so ugly about that. int~float is nothing better.
Apr 02 2009