[PATCH] revset: add experimental set subscript operator

[Yuya Nishihara]

On Fri, 30 Jun 2017 21:42:49 -0400, Matt Harbison wrote:
> On Fri, 30 Jun 2017 20:08:31 -0400, Jun Wu <quark at fb.com> wrote:
> 
> > Excerpts from Yuya Nishihara's message of 2017-06-30 23:58:43 +0900:
> >> # HG changeset patch
> >> # User Yuya Nishihara <yuya at tcha.org>
> >> # Date 1498302078 -32400
> >> #      Sat Jun 24 20:01:18 2017 +0900
> >> # Node ID b7f6740b0e58c468ecc82296fe1ee0800a7e0582
> >> # Parent  fe3419b41a456661a3d35ae963d06a203d4446a2
> >> revset: add experimental set subscript operator
> >>
> >> It only supports integer indices as a beginning. See the following post
> >> for further ideas.
> >>
> >> https://www.mercurial-scm.org/wiki/RevsetOperatorPlan#ideas_from_mpm
> >
> > Glad to see progress on new operators! The implementation looks good to  
> > me.
> >
> > Maybe this is unnecessary bike-shedding, but I feel "[]" is more natural  
> > for
> > "indexing" purpose.  "{}" is used in templates which might be confusing.

Yep. That's why I slightly prefer not using "{}".

  $ hg log -T '{revset(".{0}")}\n'
                         ^^^
                   this is not a revset operator, but expanded to ''

> That was my first thought too, but then I realized that I misunderstood  
> the purpose of this.  "Subscript/indexing" makes me think something like  
> 'parents(.)[1] == p2(.)'.  But:
> 
> $ ../hg log -r 'parents(.){0}' -T "{rev}:{node|short}\n"
> 36963:578172de2e38
> $ ../hg log -r 'parents(.){1}' -T "{rev}:{node|short}\n"
> 36964:c9925ed4a5f4
> 
> ... which follows the linked message, now that I re-read it.

That's mpm's point why he chose {} over [].

http://markmail.org/message/sjnnwa43s4eksu62

FWIW, the use of [] can be justified by considering x[n] as a sort of
a pointer arithmetic in DAG structure.

We need APL keyboard.

> IDK if that
> kind of indexing is useful for revsets, but it would be for template  
> lists.  I'd rather use [] for that, but Yuya commented about that here:
> 
> https://bz.mercurial-scm.org/show_bug.cgi?id=5534
> 
> > Templates may seem unrelated, but I think it could be embedded in  
> > revsets in
> > the future.  That enables more flexible queries, like "commits whose  
> > author
> > is the same as (antoher revset)'s author".  Template strings need some
> > function to "bind" to a ctx, like: author(template(REV, "{author}")).
> >
> >> I'm not sure if the current semantics are the most useful and  
> >> extendable.
> >> We might want the way to select the nth ancestors/descendants in sub  
> >> graph,
> >> by e.g. 'follow(filename){-2}', which is completely different so the  
> >> '{n}'
> >> operator wouldn't be usable.