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!

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)?

I think they're your #3.

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
> 
> #1 operator between (operator concatenated) array elements:
> 
> 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"

> #2 operator and "value" on each array element
> 
> 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]

> #3 operator between 2 arrays
> 
> 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

> 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?

> 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

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

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

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

>> 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

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.