www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - my ideas for array operations

reply dennis luehring <dl.soluz gmx.net> writes:
i have some ideas for array operation
hope they are "context free" and don't break any syntactic rules :-}

OP ==> + - / ~ * and all the others



syntax: array ~OP

result-type: value-type of array

examples:

[1,2,3] ~+ ==> 1+2+3 = 6

[1,3,4] ~* ==> 1*3*4 = 12

["a","b","c"] ~~ ==> "abc"



syntax: array  OP value

value: array.value/applicable-type/function

result-type: typeof(array)

[1,2,3]  + 10 ==> [1+10,2+10,3+10] = [11,12,13]

(maybe .+)



syntax: array1 OP array2

result-type: typeof(array1)

precondition:
   array1.value/applicable-type == array2.value/applicable-type
   array1.dimension == array2.dimension

[a,b,c] + [d,e,f] ==> [a+d,b+e,c+f]

usage:

double v1[3] = [1,2,3]
double v2[3] = [3,4,5]

double norm = sqrt( ( v1 * v1 ) ~+ );
double dot_prod = ( v1 * v2 ) ~+ );
double mid = ( v1 ~+ ) / v1.length;
Oct 05 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
dennis luehring wrote:

 i have some ideas for array operation
 hope they are "context free" and don't break any syntactic rules :-}
 
 OP ==> + - / ~ * and all the others
 

 
 syntax: array ~OP
 
 result-type: value-type of array
 
 examples:
 
 [1,2,3] ~+ ==> 1+2+3 = 6
 
 [1,3,4] ~* ==> 1*3*4 = 12
 
 ["a","b","c"] ~~ ==> "abc"
 

 
 syntax: array  OP value
 
 value: array.value/applicable-type/function
 
 result-type: typeof(array)
 
 [1,2,3]  + 10 ==> [1+10,2+10,3+10] = [11,12,13]
 
 (maybe .+)
 

 
 syntax: array1 OP array2
 
 result-type: typeof(array1)
 
 precondition:
   array1.value/applicable-type == array2.value/applicable-type
   array1.dimension == array2.dimension
 
 [a,b,c] + [d,e,f] ==> [a+d,b+e,c+f]
 
 usage:
 
 double v1[3] = [1,2,3]
 double v2[3] = [3,4,5]
 
 double norm = sqrt( ( v1 * v1 ) ~+ );
 double dot_prod = ( v1 * v2 ) ~+ );
 double mid = ( v1 ~+ ) / v1.length;
 


-1

Write some templates that use the existing operators.

--bb
Oct 05 2007
next sibling parent reply Gregor Richards <Richards codu.org> writes:
Bill Baxter wrote:

 dennis luehring wrote:

 i have some ideas for array operation
 hope they are "context free" and don't break any syntactic rules :-}

 OP ==> + - / ~ * and all the others



 syntax: array ~OP

 result-type: value-type of array

 examples:

 [1,2,3] ~+ ==> 1+2+3 = 6

 [1,3,4] ~* ==> 1*3*4 = 12

 ["a","b","c"] ~~ ==> "abc"



 syntax: array  OP value

 value: array.value/applicable-type/function

 result-type: typeof(array)

 [1,2,3]  + 10 ==> [1+10,2+10,3+10] = [11,12,13]

 (maybe .+)



 syntax: array1 OP array2

 result-type: typeof(array1)

 precondition:
   array1.value/applicable-type == array2.value/applicable-type
   array1.dimension == array2.dimension

 [a,b,c] + [d,e,f] ==> [a+d,b+e,c+f]

 usage:

 double v1[3] = [1,2,3]
 double v2[3] = [3,4,5]

 double norm = sqrt( ( v1 * v1 ) ~+ );
 double dot_prod = ( v1 * v2 ) ~+ );
 double mid = ( v1 ~+ ) / v1.length;


 
 -1
 
 Write some templates that use the existing operators.
 
 --bb


Agreed. Votes--. Pointless.

Besides, operators should avoid being O(n).

  - Gregor Richards
Oct 05 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Gregor Richards wrote:

 Bill Baxter wrote:

 dennis luehring wrote:

 i have some ideas for array operation
 hope they are "context free" and don't break any syntactic rules :-}

 OP ==> + - / ~ * and all the others



 syntax: array ~OP

 result-type: value-type of array

 examples:

 [1,2,3] ~+ ==> 1+2+3 = 6

 [1,3,4] ~* ==> 1*3*4 = 12

 ["a","b","c"] ~~ ==> "abc"



 syntax: array  OP value

 value: array.value/applicable-type/function

 result-type: typeof(array)

 [1,2,3]  + 10 ==> [1+10,2+10,3+10] = [11,12,13]

 (maybe .+)



 syntax: array1 OP array2

 result-type: typeof(array1)

 precondition:
   array1.value/applicable-type == array2.value/applicable-type
   array1.dimension == array2.dimension

 [a,b,c] + [d,e,f] ==> [a+d,b+e,c+f]

 usage:

 double v1[3] = [1,2,3]
 double v2[3] = [3,4,5]

 double norm = sqrt( ( v1 * v1 ) ~+ );
 double dot_prod = ( v1 * v2 ) ~+ );
 double mid = ( v1 ~+ ) / v1.length;


 -1

 Write some templates that use the existing operators.

 --bb


 
 Agreed. Votes--. Pointless.
 
 Besides, operators should avoid being O(n).
 
  - Gregor Richards



Here's a 10min prototype:

module accum;

template accum(string op, T){
     T accum(T[] array) {
         if (array.length == 0) assert(false, "Must have at least one 
element");
         if (array.length == 1) return array[0];
         mixin ("T r = array[0] "~op~" array[1];");
         foreach(elem; array[2..$]) {
             mixin ("r "~op~"= elem;");
         }
         return r;
     }
}
import std.stdio;
void main()
{
     writefln( accum!("+",int)([1,2,3,4,5]) );
     writefln( accum!("*",int)([1,2,3,4,5]) );
     writefln( accum!("~",char[])(["D"," ","pro","gramming"]) );

}

--bb
Oct 05 2007
next sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
 void main()
 {
     writefln( accum!("+",int)([1,2,3,4,5]) );
     writefln( accum!("*",int)([1,2,3,4,5]) );
     writefln( accum!("~",char[])(["D"," ","pro","gramming"]) );
 
 }


will u use these templates? why not?
should something like this in phobos? why not?

ciao dennis
Oct 05 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
dennis luehring wrote:

 void main()
 {
     writefln( accum!("+",int)([1,2,3,4,5]) );
     writefln( accum!("*",int)([1,2,3,4,5]) );
     writefln( accum!("~",char[])(["D"," ","pro","gramming"]) );

 }


 
 will u use these templates? why not?


I probably wouldn't use the functionality much at all, no matter what 
syntax it's wrapped up in.

Here's something you might like to read.
http://www.artima.com/weblogs/viewpost.jsp?thread=98196

As Guido puts it, aside from those few examples I gave above, there's 
really not that much use for that functionality.  And when it is needed 
for something other than those things it's often more readable to just 
write out the foreach.

--bb
Oct 06 2007
parent dennis luehring <dl.soluz gmx.net> writes:
 will u use these templates? why not?


 
 I probably wouldn't use the functionality much at all, no matter what 
 syntax it's wrapped up in.


me too :-) (i don't even like my syntax ideas)


 Here's something you might like to read.
 http://www.artima.com/weblogs/viewpost.jsp?thread=98196



 As Guido puts it, aside from those few examples I gave above, there's 
 really not that much use for that functionality.  And when it is needed 
 for something other than those things it's often more readable to just 
 write out the foreach.


ok maybe the array operation stuff is too special for a general 
in-language solution - thx
Oct 07 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 10/6/07, Bill Baxter <dnewsgroup billbaxter.com> wrote:

 Here's a 10min prototype:
 <snip>



      writefln( accum!("+",int)([1,2,3,4,5]) );
      writefln( accum!("*",int)([1,2,3,4,5]) );


Granted that was a ten minute prototype, but please allow me to point
out that it falls down with zero-element arrays.

int[] a;
accum!("+",int)(a) // should evaluate to 0
accum!("*",int)(a) // should evaluate to 1

I'd still vote no to the original idea though, because the language
can already do what is required. As many others have pointed out, it
would be easy to write functions like sum() and product() - and to
templatise them for any type, and to be honest, something like

int[] a;
sum(a)

really is the clearest syntax of all.
Oct 07 2007
prev sibling next sibling parent David Brown <dlang davidb.org> writes:
On Sun, Oct 07, 2007 at 10:51:23PM +0100, Janice Caron wrote:

On 10/6/07, Bill Baxter <dnewsgroup billbaxter.com> wrote:

 Here's a 10min prototype:
 <snip>



      writefln( accum!("+",int)([1,2,3,4,5]) );
      writefln( accum!("*",int)([1,2,3,4,5]) );


Granted that was a ten minute prototype, but please allow me to point
out that it falls down with zero-element arrays.

int[] a;
accum!("+",int)(a) // should evaluate to 0
accum!("*",int)(a) // should evaluate to 1

I'd still vote no to the original idea though, because the language
can already do what is required. As many others have pointed out, it
would be easy to write functions like sum() and product() - and to
templatise them for any type, and to be honest, something like


This operation (usually called 'fold') is very useful in a functional-style
of programming.  Although this can be done, to some extent, in D, it
probably isn't all that common.  Haskell provides numerous fold operations
on whether the operator is applied from the left or the right, and how the
zero term is handled (in fact, it provides an entire module of utilities,
along with a "Class", which is kind of like an interface, for things that
are foldable).

For the zero term, you can either provide what the zero element is, or
disallow the zero element case.

But, I agree, this doesn't need to be in the language, since it is easy to
write.

Dave
Oct 07 2007
prev sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 10/7/07, David Brown <dlang davidb.org> wrote:

 But, I agree, this doesn't need to be in the language, since it is easy to
 write.


It is worth pondering about efficiency though. Most especially when it
comes to concatenation. That is:

string s = cat(a,b,c,d,e,f,g,h);

ought to be more efficient than

string s = a~b~c~d~e~f~g~h;

because the former could, in principle, require only one allocation,
wheras the latter needs seven.

The fast way:
s.length = a.length + b.length + ...
s[0..a.length] = a[];
s[a.length..a.length+b.length] = b[];
...

Order O(N)

The slow way:
s = a ~ b;
s = s ~ c;
...
s = s ~ h;

Order O(N squared)
Oct 07 2007
next sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
 It is worth pondering about efficiency though. Most especially when it
 comes to concatenation. That is:
 
 string s = cat(a,b,c,d,e,f,g,h);
 
 ought to be more efficient than
 
 string s = a~b~c~d~e~f~g~h;
 
 because the former could, in principle, require only one allocation,
 wheras the latter needs seven.


only if the compiler don't understand whats going on
who says that a compiler need to seperate each concatenate in a single 
operation? its the compilers job to use an efficent way

do you think that a array slice works the same?

int b[5] = [1,2,3,4,5]
int t[3] = b[1..3]

t[0] = &b[1]
t[1] = &b[2]

btw: i understand that my idea just adress 2% of the array operations 
needs - so i rejeced it myself (clean brain again)

ciao dennis
Oct 08 2007
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 10/8/07, dennis luehring <dl.soluz gmx.net> wrote:

 only if the compiler don't understand whats going on
 who says that a compiler need to seperate each concatenate in a single
 operation? its the compilers job to use an efficent way


That's a very interesting question. I have absolutely no idea what the
answer is. Will the compiler optimize a~b~c~d~e~f~g~h into a single
allocation and some copying? I don't know. I hope so, but I suspect
not.

The existence of a cat() function would certainly encourage people to
write code in a concatenation-optimal way though.

(Note: I am /not/ suggesting that such a feature be added to D,
because the function is just too easy to write).




 do you think that a array slice works the same?


Of course not. Slicing doesn't involve /any/ allocations!
Oct 08 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Janice Caron wrote:

 On 10/8/07, dennis luehring <dl.soluz gmx.net> wrote:

 only if the compiler don't understand whats going on
 who says that a compiler need to seperate each concatenate in a single
 operation? its the compilers job to use an efficent way


 
 That's a very interesting question. I have absolutely no idea what the
 answer is. Will the compiler optimize a~b~c~d~e~f~g~h into a single
 allocation and some copying? I don't know. I hope so, but I suspect
 not.


As I wrote in my previous post (which I started before my seeing this 
post of yours) DMD will optimize into a single alloc, but GDC won't.
I've filed a bug[1] for the latter, since the multi-concat function is 
available in gphobos and is even called by the generated code but only 
for two arrays at a time (thus defeating the purpose).


[1]: http://d.puremagic.com/issues/show_bug.cgi?id=1556


 The existence of a cat() function would certainly encourage people to
 write code in a concatenation-optimal way though.
 
 (Note: I am /not/ suggesting that such a feature be added to D,
 because the function is just too easy to write).


The optimization should be pretty easy for the compiler (and is in fact 
performed by DMD, even without -O), and just using concats looks cleaner 
IMHO.
Oct 08 2007
parent "Janice Caron" <caron800 googlemail.com> writes:
On 10/8/07, Frits van Bommel <fvbommel remwovexcapss.nl> wrote:

 DMD will optimize into a single alloc


Great! Except...

How does that work for opCat() and opCatAssign()? Can those functions
accept multiple inputs? One would certainly hope so, given what you've
explained, but I've not seen it documented anywhere. It would be a
shame if user-created collections couldn't benefit from that
optimization.
Oct 08 2007
prev sibling parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Janice Caron wrote:

 On 10/7/07, David Brown <dlang davidb.org> wrote:

 But, I agree, this doesn't need to be in the language, since it is easy to
 write.


 
 It is worth pondering about efficiency though. Most especially when it
 comes to concatenation. That is:
 
 string s = cat(a,b,c,d,e,f,g,h);
 
 ought to be more efficient than
 
 string s = a~b~c~d~e~f~g~h;
 
 because the former could, in principle, require only one allocation,
 wheras the latter needs seven.
 
 The fast way:
 s.length = a.length + b.length + ...
 s[0..a.length] = a[];
 s[a.length..a.length+b.length] = b[];
 ...
 
 Order O(N)


Actually, DMD optimizes the second case by calling a special function in 
the runtime library for concatenating >2 arrays. It works in your "fast 
way".

For some reason GDC (0.24) seems to also call that function (even in the 
2-array case) but with only two arrays at a time, defeating the purpose :(.
(I only found out about this bug while writing this post, and filed a 
report: http://d.puremagic.com/issues/show_bug.cgi?id=1556)
Oct 08 2007
prev sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
 Agreed. Votes--. Pointless.


but why do we have arrays and slices and ~ as operations in language?
why do D overcomes the C++ stage of using templates for every natural 
stuff, and why should we halt to integrate some other natural feature 
for arrays into D (don't look at my syntax - just the idea behind)

i know:
-my syntax is shit
-the syntax must be clear, easy and 100% natural to use
-array operations are heavily in use
-compilers can't easily optimize huge amount of nested foreaches
...

but we can get:
-better optimisation by the compiler (think of D complex support - for 
walter; even the optimiation of a non use real part is a reason for 
integration)
-(maybe) autoparallelisation
-cleaner implementations
...


 Besides, operators should avoid being O(n).


ok array1 OP array2 is bad

but ~OP and  OP are (my) operator-specialisations; they must be O(n) :-}

ciao dennis
Oct 05 2007
parent reply Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
dennis luehring Wrote:


 Agreed. Votes--. Pointless.


 
 but why do we have arrays and slices and ~ as operations in language?
 why do D overcomes the C++ stage of using templates for every natural 
 stuff, and why should we halt to integrate some other natural feature 
 for arrays into D (don't look at my syntax - just the idea behind)
 
 i know:
 -my syntax is shit
 -the syntax must be clear, easy and 100% natural to use
 -array operations are heavily in use
 -compilers can't easily optimize huge amount of nested foreaches
 ...
 
 but we can get:
 -better optimisation by the compiler (think of D complex support - for 
 walter; even the optimiation of a non use real part is a reason for 
 integration)
 -(maybe) autoparallelisation
 -cleaner implementations
 ...
 

 Besides, operators should avoid being O(n).


 
 ok array1 OP array2 is bad
 
 but ~OP and  OP are (my) operator-specialisations; they must be O(n) :-}
 
 ciao dennis


There seems to be a tendency by some posters to opt for every possible new
language syntactic feature under the sun. A good language should be feature
rich without being verbose. Whenever there is a new problem to solve first see
how the existing tools can solve it. If they can't you may need a new feature.
Most of the time they can. Sometimes the code is inelegant and some new
syntactic sugar helps. 
So first of all what are the kinds of problem we want to solve.

* code should be easily parallelisable by the compiler on platforms that
support it.

* assign values to contents of an array.

I believe we have already borrowed array assignment from Fortran (90?)

int foo[4][4] = 5;
foo = 5;  // assign 5 to all elements in the matrix

It would be useful to do this algorithmically.
i.e.
* assign values to contents of an array based on index using a function.

pure int valueFunctor(int x,int y) {
   return x+y;
}

assignWithFunctor!(foo, valueFunctor);

sets foo to:
    0 1 2 3
    1 2 3 4
    2 3 4 5
    3 4 5 6

Similarly we would want array operations equivalent to:
     
UpdateValue!(foo, updateFunctor);    

int IncrementFunctor(int value) {
   value++;
}

int myIncrementWithIndicesFunctor(int value, int xIndex, int yIndex) {
   value+=x+y;
}

We also want to combine values somehow.

Some kind of "forall!" template. A classic usage would be calculating the
determinant of a matrix.

We want something to operate on two arrays with the same dimensions so that.

int foo[5];
int bar[5];

foo + bar  and foo +=bar do what we expect even if we have to use a template
for now.

These are easily done as library templates but the here's the catch. How do you
make it so that compiler vendors can make that library exploit native parallism
on machines that support it?
For a function the implementation can be hidden. I'm not sure if D lets you do
this with something declared a template. The object format would have to
support this or at least the export of explict specialisations such as:

  assignWithFunctor!(int[][], int delegate(int,int));

Does anyone know the answer to this.

The foreach loop already unwinds array slices and theorhetically is
parallelisable. I note that Cray's Chapel language has two variants of this.
One where the order of operations is guaranteed and one where
it is order dependent and therefore distributable.

One more thing we want is a template allowing us write a functor for matrix
multiplication

int foo[2];
int bar[2];
int foobar[2][2];

// need to find or invent the proper generic name for this
somekindofproduct!(out int[][], int[], int[], int delegate(????))

such that with the delegate set to "matrixMultiply!"

somekindofproduct!(foobar , foo, bar, matrixMultiply!);

implements matrix multiplication.
The implication here could be that we might need "template delegates" but
probably not with a little thought.

syntactic sugar for operator overloads allowing:

foobar = foo * bar;  would be nice but we can wait for things to mature first. 
The cleverness needed here is overloading based on the dimensions of the arrays
and picking up and reporting sizes mismatches at compile time. Guess what D
templates aleady let us do this. The implementation is left as an exercise :).

Bruce.

hint: I suspect we also need a library template for compileTimeError!
Oct 06 2007
parent reply dennis luehring <dl.soluz gmx.net> writes:
 There seems to be a tendency by some posters to opt for every possible new
language syntactic feature under the sun. A good language should be feature
rich without being verbose. Whenever there is a new problem to solve first see
how the existing tools can solve it. If they can't you may need a new feature.
Most of the time they can. Sometimes the code is inelegant and some new
syntactic sugar helps. 
 So first of all what are the kinds of problem we want to solve.


and there is also a tendency of some to alwayes argue against 
integration (not you) - i think most people out there have no experience 
in language development, they have much experience in library 
development - and they cannot speak in language development arguments

just a question:

how many of these anti-integrators would habe buildin the complex number 
  the gc and array slicing/concatenator, mixins and the 
default-initalizer stuff into the language?

what would happen if i ask for complex number integration now (in a 
world in which D have no support) - i think i would get the same 
results: "its too specific", "its a library thing",... "use this 
template code..."

is D still in language development phase?

maybe i need a better place for pure language development questions - a 
place where do i not receive programatical solutions to my "problems" 
but an open dicussion about the pro/cons...

and i know that language development could be like hell - D 2.0 const 
stuff i a good example what could get wrong (not everything of it)

all the ideas im trying to talk about are not 
we-should-have-this-in-D-in-a-week more like maybe-in-a-year-or-later

ciao dennis
Oct 06 2007
parent reply Christopher Wright <dhasenan gmail.com> writes:
dennis luehring wrote:

 just a question:
 
 how many of these anti-integrators would habe buildin the complex number 
  the gc and array slicing/concatenator, mixins and the 
 default-initalizer stuff into the language?


Array slicing? Very few. I hadn't seen that syntax before using D, but 
functions to do the same have usually seemed rather clunky.

Garbage collection? Since it can be disabled or worked around, few. Most 
people enjoy the leak protection, and performance-critical stuff will be 
profiled for memory usage and use manual allocation anyway.

Mixins? Damn useful. It's a way to get the benefits of code duplication 
without the costs, if nothing else. If you don't like them, you can 
ignore them (unless you're using std.signal, mutter mutter).


 what would happen if i ask for complex number integration now (in a 
 world in which D have no support) - i think i would get the same 
 results: "its too specific", "its a library thing",... "use this 
 template code..."
 
 is D still in language development phase?


Yes. But its target is a production language, not an academic one. If it 
were academic, it would be much more open to new features, but 
programmers have to remember most of the features in the language in 
order for them to be useful.

And as Daniel Keep said, map/reduce is a much more powerful, flexible, 
and traditional means of getting these operations. And map/reduce is 
highly parallelizable; a single good implementation can do for specific 
compiler support for a few particular operations.


 maybe i need a better place for pure language development questions - a 
 place where do i not receive programatical solutions to my "problems" 
 but an open dicussion about the pro/cons...


Well, you could fork GDC.


 and i know that language development could be like hell - D 2.0 const 
 stuff i a good example what could get wrong (not everything of it)
 
 all the ideas im trying to talk about are not 
 we-should-have-this-in-D-in-a-week more like maybe-in-a-year-or-later


Walter's time is not yet relevant to this discussion. My time and my 
memory, as a D user, are.

And if it were Walter's time that were important, I'm sure he could 
implement something that's no more efficient than a foreach loop in 
relatively short order and add the appropriate rules to the grammar. 
Like you said, he wouldn't get to it soon, but eventually. But I doubt 
it's going to happen.

You could ask for operators to be used as functions, though -- that way 
you could write:

reduce(+, [1, 2, 3, 4]); // returns 1 + 2 + 3 + 4

That looks cool. But I doubt it's very useful.


 ciao dennis
Oct 06 2007
parent dennis luehring <dl.soluz gmx.net> writes:
 how many of these anti-integrators would habe buildin the complex 
 number  the gc and array slicing/concatenator, mixins and the 
 default-initalizer stuff into the language?


 


i know why i like them - it was not a describe-please question
the question is how able (beside walter) are others to define what is
good for integration and what not


 what would happen if i ask for complex number integration now (in a 
 world in which D have no support) - i think i would get the same 
 results: "its too specific", "its a library thing",... "use this 
 template code..."

 is D still in language development phase?


 
 Yes. But its target is a production language, not an academic one. If it 
 were academic, it would be much more open to new features, but 
 programmers have to remember most of the features in the language in 
 order for them to be useful.


who said we need another 100 features? and who said that language 
features are academic in any way?


 And as Daniel Keep said, map/reduce is a much more powerful, flexible, 
 and traditional means of getting these operations. And map/reduce is 
 highly parallelizable; a single good implementation can do for specific 
 compiler support for a few particular operations.


that looks nice


 maybe i need a better place for pure language development questions - 
 a place where do i not receive programatical solutions to my 
 "problems" but an open dicussion about the pro/cons...


 Well, you could fork GDC.


i don't want to code - i just want to discuss some things
(and btw my idea seem to be totaly point/sensless - what should i code?)


 Walter's time is not yet relevant to this discussion. My time and my 
 memory, as a D user, are.


and thats my problem - the only one introducing new concepts are 
walter(and some others) - all others are just fighting for their right 
to have all others features library based
Oct 06 2007
prev sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
 Write some templates that use the existing operators.


and what are "Array operations" then?
http://www.digitalmars.com/d/future.html
Oct 05 2007
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
dennis luehring wrote:

 Write some templates that use the existing operators.


 
 and what are "Array operations" then?
 http://www.digitalmars.com/d/future.html


Unimplemented, with no plans to change that any time soon, AFAIK.


	-- Daniel
Oct 05 2007
parent reply dennis luehring <dl.soluz gmx.net> writes:
 Unimplemented, with no plans to change that any time soon, AFAIK.


but what are "array operations" in walters world (not in his code)?

ciao dennis
Oct 05 2007
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
dennis luehring wrote:

 Unimplemented, with no plans to change that any time soon, AFAIK.


 
 but what are "array operations" in walters world (not in his code)?
Oct 06 2007
prev sibling next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
dennis luehring wrote:

 i have some ideas for array operation
 hope they are "context free" and don't break any syntactic rules :-}


I don't think we need these.  The operators are very specific, and
aren't very obvious.  Incidentally, a lot of what you propose could be
done better, I think, with a decent functional library.


 OP ==> + - / ~ * and all the others
 

 
 syntax: array ~OP
 
 result-type: value-type of array
 
 examples:
 
 [1,2,3] ~+ ==> 1+2+3 = 6
 
 [1,3,4] ~* ==> 1*3*4 = 12
 
 ["a","b","c"] ~~ ==> "abc"


reduce((int a, int b){return a+b;}, [1,2,3]) ==> 6
reduce((int a, int b){return a*b;}, [1,3,4]) ==> 12
reduce((string a, string b){return a~b;}, ["a","b","c"]) ==> "abc"



 
 syntax: array  OP value
 
 value: array.value/applicable-type/function
 
 result-type: typeof(array)
 
 [1,2,3]  + 10 ==> [1+10,2+10,3+10] = [11,12,13]
 
 (maybe .+)


map((int a){return a+10;}, [1,2,3]) ==> [11,12,13]



 
 syntax: array1 OP array2
 
 result-type: typeof(array1)
 
 precondition:
   array1.value/applicable-type == array2.value/applicable-type
   array1.dimension == array2.dimension
 
 [a,b,c] + [d,e,f] ==> [a+d,b+e,c+f]


map((T a, T b){return a+b;}, zip([a,b,c], [d,e,f]));

These constructs are much more general, and more powerful.  And they can
be implemented as library code right now.

	-- Daniel
Oct 06 2007
parent reply dennis luehring <dl.soluz gmx.net> writes:
 These constructs are much more general, and more powerful.  And they can
 be implemented as library code right now.


and you will use them instead of writing you own foreachs?
and if not, why?
Oct 06 2007
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
dennis luehring wrote:

 These constructs are much more general, and more powerful.  And they can
 be implemented as library code right now.


 
 and you will use them instead of writing you own foreachs?
 and if not, why?


At the moment I don't because tuples got introduced and I didn't get
around to updating my functional library.  That's because I got
side-tracked by futures, which got side-tracked by thread pools which
got stalled, and then I was doing other stuff...

That said, a better example is my Python code; I frequently use
functional constructs where I can, since it tends to make the code a
hell of a lot simpler.

One other thing I realised from your examples: even if you don't like
functional coding, your first three could be solved neatly by adding
.sum, .product and .join pseudo-member functions (of which I think .join
already exists).  The trick is then to find more examples that aren't
contrived.  :P

So yes, I would use such constructs.  I just need to get around to
updating them with tuples and automatic threading.

	-- Daniel
Oct 06 2007
prev sibling parent 0ffh <spam frankhirsch.net> writes:
dennis luehring wrote:

 i have some ideas for array operation
 hope they are "context free" and don't break any syntactic rules :-}


Nice, but I don't think these are important enought to justify
new operators.

Regards, Frank
Oct 06 2007