I dun a DIP, possibly the best DIP ever

[Manu]

On Thu, Apr 23, 2020 at 2:55 PM Steven Schveighoffer via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> On 4/22/20 8:21 PM, Manu wrote:
> > On Thu, Apr 23, 2020 at 2:50 AM Steven Schveighoffer via Digitalmars-d
> > <digitalmars-d at puremagic.com <mailto:digitalmars-d at puremagic..com>>
> wrote:
> >
> >     On 4/22/20 10:37 AM, Manu wrote:
> >      > I think efficient implementation here would depend on a static
> fold,
> >      > which I plan for a follow-up, and it's a very trivial expansion
> from
> >      > this DIP.
> >      > Static reduce would allow `...` as an argument to a BinOp
> >      > Ie; `Tup + ...` would expand `Tup[0] + Tup[1] + Tup[2] + ...`
> >      > You could do `is(FindType == Tup) || ...`, and it would evaluate
> >     true if
> >      > FindType exists in Tup, with no junk template instantiations!
> >
> >     This is awesome, and I'm not seeing why you would save it for later.
> >
> >
> > Because it's strictly additive, DIP's with over-reach tend to fail.
>
> Without the folding, I think this feature leaves a lot on the table. I'd
> still be happy with the DIP as-is, but it obviously doesn't help me as
> much in the projects I'm using.
>

I think you'll discover that the map's are the more expensive operations.
You'll see a huge improvement from that alone.
If people get behind this DIP, I'm completely confident you'll get fold too.

>     In general, couldn't this DIP be done just strictly on binary
> operators
> >     and do what this DIP does with commas?
> >
> >     i.e.
> >
> >     foo(T) , ... expands to foo(T[0]), foo(T[1]), ..., foo(T[n])
> >
> >
> > That looks really grammatically challenging to me. I wouldn't know where
> > to start attempting to implement that :/
>
> Is this not the same difficulty as `Tup + ...` which is what you
> suggested above? I thought it was the same thing.


The grammar for binary expression is easy to interact with.
`,` separators are NOT a binary expression, they are frequently just
hard-wired into the grammar as separators, and so everywhere a comma
appears in the grammar where the value may be involved in an expansion need
to have grammatical modifications, and everywhere that a comma is not
present in the grammar where an expansion may be accepted must have a
grammatical modification to allow commas in that location too.

I haven't tried it, but the thought of hacking in such a change to the
grammar everywhere a comma appears terrifies me, resulting ambiguity feels
very likely.
Hooking a special token on the right of a binary expression should be a
1-line change however.

My thought was that if you went for the binary operator implementation,
> then you have one addition, instead of one now and one later, and the
> binary form can capture everything this DIP captures without needing to
> be an "additional" piece.


static fold has a degenerate edge case (empty tuple), and handling that
case has options subject to value judgement. I don't want this DIP to get
lost in that debate. There are a few reasonable options in that case, and I
could make arguments for and against each option that I can think of.
static fold is probably useful about 10% as often as static map. This DIP
as is will make the biggest impact on compile perf and brevity and we
should take it as eagerly as we are able.

We'll do fold as an immediate follow up though. If it gets in good shape
and it looks no more likely to increase controversy before the DIP's get
far through the pipeline, then maybe we can merge the DIPs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20200423/55d77e08/attachment.htm>