On Friday, 24 April 2020 at 22:21:31 UTC, Walter Bright wrote:
> I did a little research:
>
>     ∀xP(x)
>
> means:
>
>     for all x in P(x)
>
> or in ... notation:
>
>     P(x...)

Shouldn't it actually be

P(x)...

or am i misunderstanidng?

On Friday, 24 April 2020 at 22:42:13 UTC, Walter Bright wrote:
> On 4/24/2020 1:49 AM, Manu wrote:
>> static foreach is not an expression, and it's very hard to involve those result calls in some conjunction. Expand that code to || them together... it gets ugly real fast.
>> I wouldn't have wasted my time writing this DIP and a reference implementation if static foreach was fine.
>
> This is why I suggested in the "Challenge" thread that these need to be motivating examples in the proposed DIP, not the ones that are in there, which are not particularly motivating.

here is one.
For an alias seq containing the integers from 0 to 4096
construct another alias seq containing the every value of the original one with 3 added to it.
emit the last element of the newly created tuple plus the last element of the old tuple (should equal 8194) pragma(msg).

The compile time for that.
Has to take less than 50 milliseconds.
(as it does with our current proposal)

On Friday, 24 April 2020 at 22:42:13 UTC, Walter Bright wrote:
> On 4/24/2020 1:49 AM, Manu wrote:
>> static foreach is not an expression, and it's very hard to involve those result calls in some conjunction. Expand that code to || them together... it gets ugly real fast.
>> I wouldn't have wasted my time writing this DIP and a reference implementation if static foreach was fine.
>
> This is why I suggested in the "Challenge" thread that these need to be motivating examples in the proposed DIP, not the ones that are in there, which are not particularly motivating.

There is one meta answer to the challenge as well.
The solution you propose to the examples given has to be come with a a description of the rule applied, that is a simple as "All tuples which fall under constraint A create tuples, according to rule B)." Which of course pre-supposes that this will be part of the specification.

On Fri, Apr 24, 2020 at 11:00 PM Nick Treleaven via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Friday, 24 April 2020 at 08:04:29 UTC, Walter Bright wrote:
> > On 4/24/2020 1:03 AM, Walter Bright wrote:
> >> On 4/24/2020 12:10 AM, Manu wrote:
> >>>    alias Tup = AliasSeq!(0, 2, 3);
> >>>    void fun(int);
> >>>    fun(Tup);  // scalar argument receives tuple, it can
> >>> expand, so: fun(0), fun(1), fun(2)
> >>
> >> Write it as:
> >>
> >>      Tup.fun();
> >
> > Incidentally, belay that. That will currently produce: fun(0,
> > 2, 3);
>
> This syntax is an unfortunate inconsistency with your proposal, but how often is variadic UFCS used ATM? Its existence has been pointed out in a NG reply before (I think by Timon), but it seemed to surprise people. Perhaps it could be deprecated - use fun(Tup) instead. The latter is more intuitive as people tend to think UFCS is for the first argument, not multiple arguments. The spec doesn't seem to suggest variadic UFCS is supported:
>
> https://dlang.org/spec/function.html#pseudo-member
>
> > Of course,
> >
> >     fun(1, Tup);
> >
> > cannot be rewritten in this way
>
> AliasSeq!(1, Tup).fun(); // fun(1); fun(0); fun(2); fun(3);
>

I pointed out earlier, and I'll point out again, that Walter's proposal can not be applied to ANY parameter lists, because overloading and possibility for hijacking.

  int fun(int);
  fun(Tup);  ->  fun(Tup[0]), fun(Tup[1]), fun(Tup[2])

This looks intuitive, but then someone adds:

  void fun(int, int, int);

Or maybe it was already there...
So, a 2 or >=4 len tuple could expand, but a 3-len tuple would call the
3-arg overload.
What if the function has variadic args?
Hijacking possibility just wipes this whole thing off the table.

The ambiguities in Walter's suggestion are impossible to reconcile in a uniform and satisfying way. That's exactly why I moved away from that idea and towards an explicit expression. It's the only way.

On 4/24/20 7:07 PM, Adam D. Ruppe wrote:
> On Friday, 24 April 2020 at 22:21:31 UTC, Walter Bright wrote:
>> I did a little research:
>>
>>     ∀xP(x)
>>
>> means:
>>
>>     for all x in P(x)

First, please can we avoid untypeable symbols?

Second, this really is a "function" of the expression, not the tuple. A tuple already means "all it's elements". What we want to say to the compiler is to expand the expression for each of the tuple combinations included.

It's very much like array vector expressions. However, array vector expressions work across a whole statement. This cannot be that, it has to work within an expression, because you can't declare an intermediate expression like a parameter tuple. If you want to use vector expressions inside a larger expression, you can put them in a temporary first.

Is there really an issue with ... so much that we need to search for something else? Or are you complaining about the feature itself? I think the ... is pretty readable.

>>
>> or in ... notation:
>>
>>     P(x...)
> 
> Shouldn't it actually be
> 
> P(x)...

Yes.

-Steve

On Saturday, 25 April 2020 at 00:57:54 UTC, Steven Schveighoffer wrote:
> First, please can we avoid untypeable symbols?

I'm not for the symbol! I just want to verify understanding.

I'm not crazy about ... either but it does seem to be the best option available.

I plan on writing up a couple examples later but my brain isn't on point right now.

On Sat, Apr 25, 2020 at 7:00 AM Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

>
> Let's not fall into the mode of only looking at the way C++ did it and not
> seeing other ways. C++ has problems (like not having arrays) that lead it
> in
> different directions for solving array-like problems.
>

It is so predictable that you will eventually produce a sentence like this
whenever I suggest anything.
To be clear; **I started with your proposal** when thinking on this. I
quickly determined it was unworkable.
The fact that I chose the same syntax as C++ is for a few reasons:
 1. we also use `...` to build tuples, it seems natural to invoke the same
syntax here
 2. it turns out that it's grammatically unambiguous!
 3. it's familiar and unsurprising, and there's no compelling reason to
ignore the precedent in point #1 just for the sake of being different than
C++ (which would be the only argument against as far as I can tell)

It's also not a bad idea to look to acclaimed success stories for
inspiration, and I think `...` is probably C++'s biggest success story this
century.
It is not awkward or troubling in C++. It's an unusually excellent piece of
language.

With respect to D though, we gain so much more than C++ can. C++ doesn't
have tuples, but we do!
It applies with a beautiful uniformity, and it's useful in a lot more
situations and with a lot less boilerplate cruft than C++ could ever dream.
This will make junk template instantiations a thing of the past, and it's
also terse and very readable.

I can't imagine a reason to change my proposal. The only reason I would consider changing it is if you can make your (like-arrays) proposal work... but it doesn't. I explored that a lot, believe it or not. I really wanted to believe it could work.

What do other languages do? How are things like this expressed in
> mathematics?
>

C++ uses `...`, and they are the only language that has anything remotely
like this.
Javascript also uses `...` for something similar-ish, so the web guys
should find it familiar too.

On 4/24/20 9:05 PM, Adam D. Ruppe wrote:
> On Saturday, 25 April 2020 at 00:57:54 UTC, Steven Schveighoffer wrote:
>> First, please can we avoid untypeable symbols?
> 
> I'm not for the symbol! I just want to verify understanding.
> 
> I'm not crazy about ... either but it does seem to be the best option available.
> 
> I plan on writing up a couple examples later but my brain isn't on point right now.

Sorry, that was a double response, both to you and Walter.

-Steve

On Friday, 24 April 2020 at 22:21:31 UTC, Walter Bright wrote:
> On 4/24/2020 1:55 PM, Walter Bright wrote:
>> How are things like this expressed in mathematics?
>
> I did a little research:
>
>     ∀xP(x)
>
> means:
>
>     for all x in P(x)

Minor note: I don't think it means for all x _in_ P(x).  Rather, here, we're evaluating P(x) for all values of x.

If P(x) is a propositional statement (i.e. a statement about x that can be true or false), this means that ∀xP(x) represents whether P(x) is true for all x or not.

I don't recall ever seeing this notation used other than to combine propositional statements in this way.

If you want to talk about all values of a function f(x) for all values of x in some set X, then it would be an _image_ of X under f:

    f[X] = { f(x) | x ∈ X }

... so if you want to talk about all elements of a given set, it would be as simple as:

    { x | x ∈ X }

which is the source of the "list comprehension" notations you get in various languages (e.g. pythonic `x for x in X`, but also of course `f(x) for x in X`).  See:
https://en.wikipedia.org/wiki/Set-builder_notation#Parallels_in_programming_languages

On 4/24/2020 1:55 PM, Walter Bright wrote:
> Another approach to resolving the original problem (template instantiation bloat) is for the compiler to recognize templates like AliasSeq as "special" and implement them directly.
> 
> For example, AliasSeq is defined as:
> 
>    template AliasSeq(TList...) { alias AliasSeq = TList; }
> 
> This pattern is so simple it can be recognized by the compiler. (Having std.meta.AliasSeq being a special name known to the compiler is not necessary.)

Giving this a try:

https://github.com/dlang/dmd/pull/11057