On Wed, 28 May 2014 16:07:08 -0700
Walter Bright via Digitalmars-d-announce
<digitalmars-d-announce@puremagic.com> wrote:

> Some of the inconsistencies you mentioned and Brian mentioned in his talk are actually the result of consistencies.
>
> I know this is a bit of a difficult thing to wrap one's head around, but having something be mathematically consistent and humanly consistent are often at severe odds.

I don't disagree, but I also think that we need to be very careful when they're at odds, because it tends to result in buggy code when the rules are inconsistent from the human's perspective. In some cases, it's best to better educate the programmer, whereas in others, it's better to just make it consistent for the programmer - especially when you're dealing with a case where being consistent with one thing means being inconsistent with another. Overall, I think that we've done a decent job of it, but there are definitely places (e.g. static array declarations) where I think we botched it.

- Jonathan M Davis

On 05/29/2014 05:35 AM, Jonathan M Davis via Digitalmars-d-announce wrote:
> On Wed, 28 May 2014 16:07:08 -0700
> Walter Bright via Digitalmars-d-announce
> <digitalmars-d-announce@puremagic.com> wrote:
>
>> Some of the inconsistencies you mentioned and Brian mentioned in his
>> talk are actually the result of consistencies.
>>
>> I know this is a bit of a difficult thing to wrap one's head around,
>> but having something be mathematically consistent and humanly
>> consistent are often at severe odds.
>
> I don't disagree, but I also think that we need to be very careful when
> they're at odds, because it tends to result in buggy code when the rules are
> inconsistent from the human's perspective. In some cases, it's best to better
> educate the programmer, whereas in others, it's better to just make it
> consistent for the programmer - especially when you're dealing with a case
> where being consistent with one thing means being inconsistent with another.
> Overall, I think that we've done a decent job of it, but there are definitely
> places (e.g. static array declarations) where I think we botched it.
>
> - Jonathan M Davis
>

I think this is not a point about "consistency", but about intuition.

In any case, simply reversing the order for static array types using an ad-hoc rewrite rule would be a huge wart, even more severe than the other points you raised, and we definitely wouldn't be trading one kind of consistency for another.

(In any case, the most elegant solution is to simply not have special syntax for language built-in types.)

On Thu, 29 May 2014 08:23:26 +0200
Timon Gehr via Digitalmars-d-announce
<digitalmars-d-announce@puremagic.com> wrote:

> In any case, simply reversing the order for static array types using an ad-hoc rewrite rule would be a huge wart, even more severe than the other points you raised, and we definitely wouldn't be trading one kind of consistency for another.

In every other case, array dimensions are read from left-to-right, and thanks
to
    const(int)* foo;

we already threw out the whole idea of types really being read outward from the variable name, and outside of static arrays, I don't think that we have anything that would even care if we declared that types were always read left-to-right. If we had always had static array dimensions be read left-to-right in their declarations, I very much doubt that you would have much of anyone complaining about it being inconsistent. If anything, that's _more_ consistent with everything else. It's just that that doesn't fit with how C/C++ compilers read types.

The only reason that I don't argue strongly for changing it is the fact that it would break every existing program which uses multi-dimensional static arrays, and the breakage would be easy to miss at compile time. So, unfortunately, I think that we're stuck. But aside from arguing that it's how C/C++ reads types, I don't see much of an argument for why it makes any sense for static array dimensions be read from right-to-left in declarations.

- Jonathan M Davis

On 05/29/2014 12:59 AM, Jonathan M Davis via Digitalmars-d-announce wrote:

> So, unfortunately, I think that we're stuck.

You make it sound like there is a problem. ;)

> I don't see much of an argument for why it makes any sense for static array
> dimensions be read from right-to-left in declarations.

Language does not say anything about how people read declarations. Both static array dimensions and indexing are consistent currently in D.

When declaring, it is always

    Type[length]

when indexing it is always

    arr[index]

Note that there is no such thing as a multi-dimensional array in C, C++, or D. Hence, there is no reading from any direction; there is a simple and consistent syntax.

Ali

On Thu, 29 May 2014 01:31:44 -0700
Ali Çehreli via Digitalmars-d-announce
<digitalmars-d-announce@puremagic.com> wrote:

> On 05/29/2014 12:59 AM, Jonathan M Davis via Digitalmars-d-announce wrote:
>
>  > So, unfortunately, I think that we're stuck.
>
> You make it sound like there is a problem. ;)
>
>  > I don't see much of an argument for why it makes any sense for
>  > static
> array
>  > dimensions be read from right-to-left in declarations.
>
> Language does not say anything about how people read declarations. Both static array dimensions and indexing are consistent currently in D.
>
> When declaring, it is always
>
>      Type[length]
>
> when indexing it is always
>
>      arr[index]

It's consistent until you have multiple dimensions. Then you end up with the dimensions being listed right-to-left for static array declarations and left-to-right in all other cases.

> Note that there is no such thing as a multi-dimensional array in C, C++, or D. Hence, there is no reading from any direction; there is a simple and consistent syntax.

??? C, C++, and D all have multi-dimensional arrays. e.g.

    int a[5][6]; // C/C++
    int[6][5] a; // D
    int** a;     // C/C++
    int[][] a;   // D
    int* a[5];   // C/C++
    int[5][] a;  // D

I don't see how you could argue that they don't have multi-dimensional arrays.

- Jonathan M Davis

On Thursday, 29 May 2014 at 10:01:17 UTC, Jonathan M Davis via Digitalmars-d-announce wrote:
>
> ??? C, C++, and D all have multi-dimensional arrays. e.g.
>
>     int a[5][6]; // C/C++
>     int[6][5] a; // D
>     int** a;     // C/C++
>     int[][] a;   // D
>     int* a[5];   // C/C++
>     int[5][] a;  // D
>
> I don't see how you could argue that they don't have multi-dimensional arrays.

I'd guess he's contrasting with the semantics offered by array-oriented languages.  For example, can you determine the rank of those arrays programmatically in constant time?  Does the type system understand the shape, and can it be reshaped trivially?  Does an operator or function expecting rank n automatically lift to higher ranks?  That sort of stuff.

Maybe D does something I haven't learned about (yet) in that area, but I know C and C++ do not (hence the heap corruption I've been hunting all week).

-Wyatt

On 05/29/2014 03:00 AM, Jonathan M Davis via Digitalmars-d-announce wrote:

> On Thu, 29 May 2014 01:31:44 -0700
> Ali Çehreli via Digitalmars-d-announce

>> Note that there is no such thing as a multi-dimensional array in C,
>> C++, or D. Hence, there is no reading from any direction; there is a
>> simple and consistent syntax.
>
> ??? C, C++, and D all have multi-dimensional arrays. e.g.

I think we finally see the cause of the disagreement. Those languages do not provide a construct called multi-dimensional array. Multi-dimensional arrays emerge as an application artifact when the programmer defines an array where the element type is an array.

Being able to create arrays of arrays by the following syntaxt does not change that fact. The followin syntax is just a convenience:

    auto bar = new int[][][](6, 5, 4);

>      int a[5][6]; // C/C++
>      int[6][5] a; // D
>      int** a;     // C/C++

That is a single pointer to a single pointer. Using it as an array is faith-based programming but what can one do? :)

>      int[][] a;   // D
>      int* a[5];   // C/C++

That is an inconsistency in C and C++. See, how the element type is on the left of the identifier? That is not the case when the element type is an array. Coping from above:

>      int a[5][6]; // C/C++

Do you see the problem there? It is not written with the same syntax when the element type was a pointer:

    int[6] a[5];    // not legal C or C++ syntax

There: C and C++ are inconsistent.

>      int[5][] a;  // D
>
> I don't see how you could argue that they don't have multi-dimensional arrays.

Their specs don't have such a thing. It is possible to have arrays where elements are arrays but that does not make those concepts language constructs.

This whole issue goes well with Scott's presentation: If it is simple to describe then we ded right. Repeating myself, the following is all one needs for the array definition syntax in D:

  Type[length] identifier;

(And of course even this: 'Type[] identifier;')

Done. Now we can go wild with it to define more complex types.

That's not the case with C arrays: One needs to learn a new syntax for arrays of arrays there.

Ali

On Thu, 29 May 2014 07:32:48 -0700
Ali Çehreli via Digitalmars-d-announce
<digitalmars-d-announce@puremagic.com> wrote:

> On 05/29/2014 03:00 AM, Jonathan M Davis via Digitalmars-d-announce
> wrote:
>  > I don't see how you could argue that they don't have
> multi-dimensional arrays.
>
> Their specs don't have such a thing. It is possible to have arrays where elements are arrays but that does not make those concepts language constructs.

And how as an array of arrays _not_ a multi-dimensional array? As far as I can tell, they're exactly the same thing just phrased differently.

- Jonathan M Davis

On 05/29/2014 08:22 AM, Jonathan M Davis via Digitalmars-d-announce wrote:

> On Thu, 29 May 2014 07:32:48 -0700
> Ali Çehreli via Digitalmars-d-announce
> <digitalmars-d-announce@puremagic.com> wrote:
>
>> On 05/29/2014 03:00 AM, Jonathan M Davis via Digitalmars-d-announce
>> wrote:
>>   > I don't see how you could argue that they don't have
>> multi-dimensional arrays.
>>
>> Their specs don't have such a thing. It is possible to have arrays
>> where elements are arrays but that does not make those concepts
>> language constructs.
>
> And how as an array of arrays _not_ a multi-dimensional array? As far as I can
> tell, they're exactly the same thing just phrased differently.

It is not a multi-dimensional array from the point of view of the language spec. There is no such thing. Although, I agree that it exists as a concept and in human speech.

What you seem to expect from the language is the acceptance of the concept of multi-dimensional array as a first-class language construct. You want the language to have a special multi-dimensional array declaration syntax.

What I am saying is that since there is no such language construct, coming up with a special syntax just to satisfy some of the users would be an inconsistency in the language, which contradicts what everybody is looking for (Scott, you, be, etc. :) )

>
> - Jonathan M Davis
>

Ali