"Bent Rasmussen" <exo@bent-rasmussen.info> wrote in message news:cchj59$1pec$1@digitaldaemon.com...
> Yes, thanks for D, its great.

You're welcome

> Walter may resemble Santa but he ain't got unlimited resources. :-)

I hope that someday we'll get a corporate sponsor with deep pockets. As it is today, D is entering corporate programming at the grass roots level. Soon, managers will look around and notice that half their projects are in D!

Andy Friesen wrote:

> Norbert Nemec wrote:
>> It should be:
>> 
>> -----------------------
>> char[] toString(char c)
>> {
>>         char[] result = new char[1];
>>         result[0] = c;
>>         return result;
>> }
> 
> Or just:
> 
>      char[] toString(char c) { return (&c)[0..1].dup; }

That's neat! I really need to learn thinking D...

Walter wrote:
> "Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:ccgikc$92e$1@digitaldaemon.com...
> 
>> I went to all the trouble to start this list.  And I'm quite sure I'm not the only one waiting for the items on it (some getting rather old now) to finally be dealt with.
>> 
>> As you see, they roughly fall into three categories: - fixes that need to be coded up - fixes that have already been written, and just need hooking up - places where it's merely the documentation that needs finishing
>> 
>> Walter, could we please at least have a clue of where these are in your queue?
> 
> There are hundreds of items in the bug list, I try to give priority to crashers. Anyhow, I've stopped adding new features, and have just been working the bug list.

I see, so as long as you're in control, that's OK.

But I am particularly surprised at how late you've left implementation of array arithmetic.  Let's just hope there's still time to test this corner of the spec!

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:

> But I am particularly surprised at how late you've left implementation of array arithmetic.  Let's just hope there's still time to test this corner of the spec!

I'm not yet convinced of that concept for array operations in the specs. It is a simple concept (which certainly is good), but I fear that it is neither very flexible nor extensible.

=================================

First, the analogy given in the specs to explain array operations: this implies that a certain order of evaluation is guaranteed. This kind of operation would be mere syntactic sugar for "for"-loops. Vectorization is far more than that.

Furthermore: trying to understand the specs, there would be nothing like an "array expression". Only "array statements". (Even though the specs erraneously talk of "expressions")

For example:

----------
void myfunc(real[] x) {
        return ...;
}

real[] a = ...;
real[] b = ...;

myfunc(a[] + b[]);
-----------

This will not work, since the last line would be interpreted as

-----------
for (i = 0; i < a.length; i++)
    myfunc(a[i] + b[i]);
-----------


=================================

The concept I have of "array expressions" is fundamentally different:

        a[] + b[]

itself would be an expression of the type of an array. You really build up expressions from arrays.

Anyhow: this concept taken alone is not extensible. You can have a certain number of operators defined on arrays, but defining your own array-functions would only be possible using a "for" loop. This loop would break vectorization and require a temporary copy of the data. In some cases, the compiler might be able to optimize this away, but in general, this will not be possible.

To make the concept of "array expressions" extensible, I came up with the idea of "vector expressions" similar to:

        [i=0..10](a[i] + b[i])  // still haven't found any better syntax for it

these allow to build the most general vectorized expressions from simple, scalar building-blocks. For simple expressions, you could use the index-free notation, for anything more complicated, you can fall back to the full-fledged index-notation.

================================

Now, why do I bring this up at this point: as I understand it, the Array Operations described in the specs (and not yet implemented) are fundamentally incompatible with the concept of real "array expressions". Pushing for the implementation of array operations now will lead to troubles when array expressions are to be introduced some day. I would rather have neither of them in 1.0 then the quick-and-dirty concept that is in the specs.

B.t.w: Array assignments should not be a problem. They would look the same in both concepts.

Ciao,
Nobbi

Norbert Nemec wrote:

<snip>
> First, the analogy given in the specs to explain array operations:
> this implies that a certain order of evaluation is guaranteed. This
> kind of operation would be mere syntactic sugar for "for"-loops.
> Vectorization is far more than that.

Not sure what you mean by that.

> Furthermore: trying to understand the specs, there would be nothing
> like an "array expression". Only "array statements". (Even though the
> specs erraneously talk of "expressions")

It is a simple matter of overloading the arithmetic operators themselves
for arrays.  Just looking at it....

----------
So, for the expression:

	a[] = b[] + 3;


the result is equivalent to:

	for (i = 0; i < a.length; i++)
	    a[i] = b[i] + 3;

----------

Notice the word "result".  From a semantic point of view, b[] + 3 is
simply an expression that evaluates to an array.

> For example:
> 
> ---------- void myfunc(real[] x) { return ...; }
> 
> real[] a = ...; real[] b = ...;
> 
> myfunc(a[] + b[]); -----------
> 
> This will not work, since the last line would be interpreted as
> 
> ----------- for (i = 0; i < a.length; i++) myfunc(a[i] + b[i]); -----------

Similarly, a[] + b[] evaluates to an array.  Which is what myfunc
expects, so there's no problem there.

> =================================
> 
> The concept I have of "array expressions" is fundamentally different:
> 
> 
> a[] + b[]
> 
> itself would be an expression of the type of an array. You really
> build up expressions from arrays.

That is indeed how I understand it to work.  That for loop is purely for
illustration, not to define the semantics.  Also, notice that this

----------
	for (i = n; i < m; i++)
	    a[i] op e;
----------

if strictly interpreted, only follows if op is an assignment operation.
 Even then it's not quite right, as that for loop doesn't return the array from the expression.

What is actually meant AFAICS is exactly as you suggest they should
work.  That is:

	T temp = new T[m-n];
	for (i = n; i < m; i++)
	    temp[i-n] = a[i] op e;
	return temp;

> Anyhow: this concept taken alone is not extensible. You can have a certain number of operators defined on arrays, but defining your own array-functions would only be possible using a "for" loop. This loop would break vectorization and require a temporary copy of the data.  In some cases, the compiler might be able to optimize this away, but in general, this will not be possible.

By "vectorization" do you mean the possibility of optimising elementwise formulas to be evaluated without storing intermediate arrays, and possibly in parallel?  Maybe a future D feature (perhaps a function attribute) combined with these array expressions could accommodate this.

<snip>
> Now, why do I bring this up at this point: as I understand it, the Array Operations described in the specs (and not yet implemented) are fundamentally incompatible with the concept of real "array expressions". Pushing for the implementation of array operations now will lead to troubles when array expressions are to be introduced some day.

From the FAQ:

"The programming community is better served by multiple implementations
competing on quality of code generated rather than by which corners of
the spec are implemented at all."

Oh dear, now we're already inviting competition on which corners of the spec are implemented.

> I would rather have neither of them in 1.0 then the quick-and-dirty concept that is in the specs.

In your interpretation of the specs, I think you'll find.

If we're going to leave it out at this stage, it will need to be specified as implementation-optional and define a version identifier for it, the way the inline assembler is already.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the
unfortunate victim of intensive mail-bombing at the moment.  Please keep
replies on the 'group where everyone may benefit.

Stewart Gordon wrote:

> Norbert Nemec wrote:
> 
> <snip>
>> First, the analogy given in the specs to explain array operations: this implies that a certain order of evaluation is guaranteed. This kind of operation would be mere syntactic sugar for "for"-loops. Vectorization is far more than that.
> 
> Not sure what you mean by that.

"Vectorization" means: the language explicitely does not guarantee any order of execution, thereby allowing the compiler reordering without further checks.

The "definition by analogy" that is used in the specs misses this fact.

>> Furthermore: trying to understand the specs, there would be nothing like an "array expression". Only "array statements". (Even though the specs erraneously talk of "expressions")
> 
> It is a simple matter of overloading the arithmetic operators themselves for arrays.  Just looking at it....
> 
> ----------
> So, for the expression:
> 
> a[] = b[] + 3;
> 
> 
> the result is equivalent to:
> 
> for (i = 0; i < a.length; i++)
> a[i] = b[i] + 3;
> 
> ----------
> 
> Notice the word "result".  From a semantic point of view, b[] + 3 is simply an expression that evaluates to an array.

Wrong. What you are quoting is an example, not the definition. The definion, though, is a bit unclear and needs for interpretation based on the example.

The definition is

----------------------
In general, (a[n..m] op e) is defined as:
        for (i = n; i < m; i++)
            a[i] op e;
----------------------

taken by word, this is nonsense. You cannot define an expression by a statement! Just consider

        myfunc(a[] + b[]);

should this be turned into

        myfunc(for (i = n; i < m; i++) a[i] + b[i])

??!! The only way you could possibly read this definition, is, on a per-statement basis. Take the whole statement and wrap it up into a for loop. Anyhow, this interpretation would give you

        for (i = n; i < m; i++)
                myfunc(a[i] + b[i]);

Which would make sense syntactically, but probably is not what you want.

We can continue like this, but I don't think it would be leading very far. Bottom line: the specs are not clearly saying what array operations really are. Taking the definition by word gives you nonsense, and trying to understand the "spirit" of the definition, we obviously agree.

Before implementing any feature, and even before doing any serious discussion of it, we should really have a clear definition.

Ciao,
Norbert