On Wednesday, 29 August 2018 at 19:56:31 UTC, Everlast wrote:
> On Tuesday, 28 August 2018 at 22:01:45 UTC, Paul Backus wrote:
>> [...]
>
> One of the things that makes a good language is it's internal syntactic consistency. This makes learning a language easier and also makes remembering it easier. Determinism is a very useful tool as is abstraction consistency. To say "Just except D the way it is" is only because of necessity since that is the way D is, not because it is correct. (There are a lot of incorrect things in the world such as me "learning" D... since I've been programming in D on and off for 10 years, I just never used a specific type for variadics since I've always use a variadic type parameter)
>
> To justify that a poor design choice is necessary is precisely why the poor design choice exists in the first place. These are blemishes on the language not proper design choices.  For example, it is necessary for me to pay taxes, but it does not mean that taxes are necessary.

Actual syntax work with more then slices...:

import std.algorithm : equal;

void foo(size_t N)(int[N] args...){
    assert(args[].equal([1, 2, 3, 4, 5]));

}

void main(){
    foo(1, 2, 3, 4, 5);
}

On Wednesday, 29 August 2018 at 19:56:31 UTC, Everlast wrote:
> One of the things that makes a good language is it's internal syntactic consistency. This makes learning a language easier and also makes remembering it easier. Determinism is a very useful tool as is abstraction consistency. To say "Just except D the way it is" is only because of necessity since that is the way D is, not because it is correct. (There are a lot of incorrect things in the world such as me "learning" D... since I've been programming in D on and off for 10 years, I just never used a specific type for variadics since I've always use a variadic type parameter)
>
> To justify that a poor design choice is necessary is precisely why the poor design choice exists in the first place. These are blemishes on the language not proper design choices.  For example, it is necessary for me to pay taxes, but it does not mean that taxes are necessary.

The syntax *is* consistent. In `foo(int[] a...)`, `int[]` is the type of the parameter, and `a` is its name. This is consistent with how all other function parameters are declared. The only difference is in how arguments are bound to that parameter. That's what the `...` signifies: that a single parameter will accept multiple arguments. It's really quite straightforward and orthogonal.

On Wednesday, 29 August 2018 at 21:14:59 UTC, Paul Backus wrote:
> On Wednesday, 29 August 2018 at 19:56:31 UTC, Everlast wrote:
>> One of the things that makes a good language is it's internal syntactic consistency. This makes learning a language easier and also makes remembering it easier. Determinism is a very useful tool as is abstraction consistency. To say "Just except D the way it is" is only because of necessity since that is the way D is, not because it is correct. (There are a lot of incorrect things in the world such as me "learning" D... since I've been programming in D on and off for 10 years, I just never used a specific type for variadics since I've always use a variadic type parameter)
>>
>> To justify that a poor design choice is necessary is precisely why the poor design choice exists in the first place. These are blemishes on the language not proper design choices.  For example, it is necessary for me to pay taxes, but it does not mean that taxes are necessary.
>
> The syntax *is* consistent. In `foo(int[] a...)`, `int[]` is the type of the parameter, and `a` is its name. This is consistent with how all other function parameters are declared. The only difference is in how arguments are bound to that parameter. That's what the `...` signifies: that a single parameter will accept multiple arguments. It's really quite straightforward and orthogonal.

No it is not! you have simply accepted it to be fact, which doesn't make it consistent.

If you take 100 non-programmers(say, mathematicians) and ask them what is the natural extension of allowing an arbitrary number of parameters knowing that A is a type and [] means array and ... means an arbitrary number of, they will NOT think A[]... makes sense.

... itself already includes the concept of an array(list or sequence) so having both [] and ... is either redundant or implies a different meaning.


To prove you are wrong in one fell swoop:

Suppose you you want to create a function that takes an arbitrary number of arrays of ints, e.g.,

foo([1,2,3], [4,2], [4,5,6,7])
foo([1,2,3])
foo([4,56,64], [4324,43,43], [4,2,2], [4,4,2,4,4,3,4], ...) // where ... has a specific mathematical notation(that all people familiar with mathematics understands as " continues in the same manner").

How is foo defined in the most direct type specified way?

Of course, you will give me the D way, because you assume the D way is the correct natural way... simply because you start with your conclusion that what D does is the correct and natural way.

The real natural way is:

foo(int[] a...)

but in D we have to do

foo(int[][] a...)

by your logic

Now, the natural way is

foo(int[] a...)

Why?

because bar(int a...) is the natural way to create a function bar that accepts an arbitrary(the ... tells us this) of ints)

Why? because bar(int a) would take one int, and bar(int a, int b) takes two, and bar(int a, int b, int c) takes three and therefor bar(int a...) takes an arbitrary number of ints.

Having to add [] only adds an extra set of symbols that means nothing if ... would be correctly interpreted.

If I'm wrong, then you have to prove why a syntax such as bar(int a...) cannot be interpreted singularly in the way I have specified.

Again, just because D does it this way doesn't mean it is the best way.

If you want to start from your conclusion that everything that D does is perfectly correct then there is little point in debating this...

On Wednesday, 29 August 2018 at 22:18:09 UTC, Everlast wrote:
> No it is not! you have simply accepted it to be fact, which doesn't make it consistent.
>
> If you take 100 non-programmers(say, mathematicians) and ask them what is the natural extension of allowing an arbitrary number of parameters knowing that A is a type and [] means array and ... means an arbitrary number of, they will NOT think A[]... makes sense.

Has anyone actually done such a survey? If not, how can you possibly be sure what the result will be?

> If I'm wrong, then you have to prove why a syntax such as bar(int a...) cannot be interpreted singularly in the way I have specified.

Of course, there's no inherent reason why `bar(int a...)` couldn't be interpreted the way you've specified. But there's also no reason why we couldn't use `bar(int... a)`, like Java, or `bar(params int[] a)`, like C#, or any of the other syntaxes you can see if you visit the Rosetta Code page on variadic functions. [1]

All programming languages are artificial. All syntax is arbitrary. What feels "natural" to you is not a universal truth, but a matter of personal taste and preference. To an experienced Scheme programmer, `(foo . args)` probably feels more natural than any of the examples I've mentioned. To an experienced APL programmer, the entire idea of a separate syntax for variadic functions probably sounds ridiculous.

Personally, I find the most pragmatic approach to be "when in Rome, do as the Romans do." So when I'm programming in D, I write `foo(int[] a...)`, and when I'm programming in Python, I write `foo(*args)`, and when I'm programming in C, I write `foo(...)` and `#include <stdarg.h>`. If your goal is to solve actual problems, arguing about syntactic minutiae is a waste of time.

[1] https://rosettacode.org/wiki/Variadic_function

On Wednesday, 29 August 2018 at 22:18:09 UTC, Everlast wrote:
> If you take 100 non-programmers(say, mathematicians) and ask them what is the natural extension of allowing an arbitrary number of parameters knowing that A is a type and [] means array and ... means an arbitrary number of, they will NOT think A[]... makes sense.

A mathematician wouldn't see much difference between different types of sequences. D supports the mathematical notion of a sequence of duck typed objects in the form of variadic templates:

void f(A...)(A args){...}

On Thursday, 30 August 2018 at 00:10:42 UTC, Paul Backus wrote:
> On Wednesday, 29 August 2018 at 22:18:09 UTC, Everlast wrote:
>> No it is not! you have simply accepted it to be fact, which doesn't make it consistent.
>>
>> If you take 100 non-programmers(say, mathematicians) and ask them what is the natural extension of allowing an arbitrary number of parameters knowing that A is a type and [] means array and ... means an arbitrary number of, they will NOT think A[]... makes sense.
>
> Has anyone actually done such a survey? If not, how can you possibly be sure what the result will be?
>
>> If I'm wrong, then you have to prove why a syntax such as bar(int a...) cannot be interpreted singularly in the way I have specified.
>
> Of course, there's no inherent reason why `bar(int a...)` couldn't be interpreted the way you've specified. But there's also no reason why we couldn't use `bar(int... a)`, like Java, or `bar(params int[] a)`, like C#, or any of the other syntaxes you can see if you visit the Rosetta Code page on variadic functions. [1]
>
> All programming languages are artificial. All syntax is arbitrary. What feels "natural" to you is not a universal truth, but a matter of personal taste and preference. To an experienced Scheme programmer, `(foo . args)` probably feels more natural than any of the examples I've mentioned. To an experienced APL programmer, the entire idea of a separate syntax for variadic functions probably sounds ridiculous.

This is not true! You claim that I'm making a blanket statement about what mathematicians would view then you do the same.

Not everything in the universe is arbitrary(if so, prove it! ;)

In any case, even if you were right, there is still a partial ordering of nationality based on other things that are pre-existing.


> Personally, I find the most pragmatic approach to be "when in Rome, do as the Romans do." So when I'm programming in D, I write `foo(int[] a...)`, and when I'm programming in Python, I write `foo(*args)`, and when I'm programming in C, I write `foo(...)` and `#include <stdarg.h>`. If your goal is to solve actual problems, arguing about syntactic minutiae is a waste of time.

This may be true but it also leads to doing what Romans do such as wiping their asses which rocks. It is only necessary if you don't have anything else but it doesn't mean there isn't a better way. The only reason why programing languages allow flaws(that then become "Features") is for "backwards compatibility".

To put this to rest: I'll make a D fork where it simply requires all characters of the input to be duplicated(so it simply removes every other character in the source then passes it to the D compiler)...

You wouldn't claim that the fork is fine because "Do as the Romans do" logic would you? You would say that it is a pointless syntax... Hence, you would think just like I'm thinking about the []. On some meaningless level you can claim the fork is valid, but you wouldnn't program in it for obvious reasons.

So, just because [] is a much less obvious issue doesn't change the fact that, at least so far since you haven't pointed out any valid reasons why it is necessary, that it is the same fundamental problem as the D fork described above.

In both cases they are valid syntaxes w.r.t. to the D compiler and fork resp. and in both cases they are unnecessary syntaxes that offer nothing new and over complicate things. The the only reason they seem different is because variadic types are not used as often as having to double every character.

Also, we are talking about the semantics of ... and not [] ultimately. My point is that by interpreting ... properly there is no reason to express [] and that this is a D flaw in over complicating the syntax for no good reason.

If we are just talking about what D requires then there is nothing to talk about... and that should be obvious.

On Thursday, 30 August 2018 at 21:40:40 UTC, Everlast wrote:
> On Thursday, 30 August 2018 at 00:10:42 UTC, Paul Backus wrote:
>> [...]
>
> This is not true! You claim that I'm making a blanket statement about what mathematicians would view then you do the same.
>
> [...]

If ... implies "an arbitrary number of" and you have:

(A...)(A a)
(A)(A a...)

A... = an arbitrary number of types
A a... = an arbitrary number of parameters *typed* as A.

When you have a list of Ts the type is denoted as "T[]". This is consistent with D's type system.