"Array slice with interval of -1" case doesn't match the path $[2:1]

[gregsdennis]

Given the title, I would expect the path to be $[2:1:-1] (which Manatee.Json will happily return successfully).

Is the -1 implied by the fact that the start is greater than the end? If that's the case, then maybe change the title to "Array slice with implied interval of -1".

[gregsdennis]

Secondarily, since the consensus is [], wouldn't that mean that most implementations interpret this as "if start <= end, return empty"? If the implied index is -1, I'd expect the output to be ["third"].

[remorhaz]

Goessner mentions ECMASCRIPT 4 proposal for the array slices syntax; ES4 was abandoned, but the proposal itself can be seen here. In fact, the proposal tells us that it's "strikingly similar" to the one implemented in Python; that allows to use Python as a convenient acceptance testing tool for our own slices implementations:

>>> x = [1,2,3]
>>> x[2:1]
[]

[gregsdennis]

While interesting, you don't really answer the specifics of my question. How is that slice to be interpreted?

[remorhaz]

How is that slice to be interpreted?

Well, you can consider iterating slice as: starting at "start" index, adding "step" on each iteration until index is outside of range (something close to "for" control structure in many languages). Note that I've said "index", not "start":

>>> x = [1,2,3]
>>> x[1]
2
>>> x[-2]
2

You can see that both 1 and -2 "start value" ponts to the same array item; there's no difference which one we use:

>>> x[1:3]
[2, 3]
>>> x[-2:3]
[2, 3]

Let's follow the steps of the last example:

0. Given: start is -2, index at start is 1; end is 3, index at end is 3.
1. We set current index to index at start which is 1; current index is lesser than index at end which is 3, so the value at index 1 is 2.
2. We add step (which is 1 by default) to current index, setting it to 2; it is still lesser than 3, so the value at index 2 is 3.
3. We add step (which is 1) to current index, setting it to 3; now it is not lessser than 3, so we stop.

Now let's look at your exapmple:

>>> x=['first','second','third','fourth']
>>> x[2:1]
[]

Let's follow the steps:

0. Given: start is 2, index at start is 2; end is 1, index at end is 1.
1. We set current index to index at start which is 2; it's not lesser that index at end which is 1, so we stop.

So, back to your question:

Is the -1 implied by the fact that the start is greater than the end?

The default step is still 1 for [2:1], but interval of the range can be considered as -1 (because 1 - 2 = -1). But I agree that it's not very intuitive.

[cburgmer]

The name including "interval -1" is a recent one. Happy to clarify and rename. Note that following the name documentation, the name of the query is supposed to describe the selector (and document the selector operates on), not the intent/outcome of the query. This should help us stay as unbiased as possible. What would you suggest?

[remorhaz]

Just a proposal: Array slice with negative range and positive step and so on?

[cburgmer]

Would you also rename the query currently called "interval 0"? If so, how? I am trying to aim for some consistency to help clarify (less is more) and help in grouping similar queries (currently done via alphabetic ordering).

[remorhaz]

I guess you can operate pozitive/negative/zero range and positive/negative/zero step and propbably array overflow/underflow for "stepping" out of array's natural range.

[remorhaz]

And I think it would be good to clearly separate the query description from test data. For example:

Query: array slice with negative range and positive step.
Data: array containing whole range.

In this case, you can group similar (not always exactly the same) queries running on different data, thus giving more clear picture of query behavior.

[cburgmer]

And I think it would be good to clearly separate the *query description* from *test data*. For example: Query: array slice with negative range and positive step. Data: array containing whole range.

This I wanted to tackle using the "on" phrase structure. Omitting it for the default scenario and adding it for further cases on different input. Can you see the relevant paragraph in the naming schema description?

…

[remorhaz]

Can you see the relevant paragraph in the naming schema description?

Yep, and that will work, of course. Yet I feel that splitting the description into separate descriptions for query and data:

• will work better that seeking for a small on in a long and complex description (that can theoretically contain another on for some reason);
• will allow to describe each part with more than one sentence.

As I've said, it's just a proposal. On my job I deal a lot with all sorts of unit-like tests and it's always a huge problem to put all the details in standard 3-part (object - pre-condition - behavior).

[cburgmer]

Let's separate the two issues.

Feel free to raise a PR for the "interval" issue here. 

For a clearer separation of selector and document (the pair I call query) I also welcome a concrete suggestion as issue or PR. 

[gregsdennis]

@remorhaz thank you for the explanation. Separating the concepts of interval vs step is the key here.

[cburgmer]

Does PR #31 match your expectation?

[gregsdennis]

Yeah. My main source of confusion was the "interval" thing. I didn't understand and was reading it as the step. It's all good.

[cburgmer]

Merged.