[Clarity] Slice n items from sequence

[njordhov]

The slice function in development for Stacks 2.1 does not adequately infer the length of the resulting sub-sequence, but instead assigns it to have the same max length as the input sequence. This will make cost estimates unnecessarily high.

The current implementation "return a sub-sequence of that starts at left-position (inclusive), and ends at right-position (non-inclusive)". This makes it infeasible (given the runtime limitations) to infer the length of the result sequence unless both bounds are integer constants, even in cases when the length of the result is known, such as:

(slice "abcdefgh" index (+ index 2))   ;; return a subsequence of two characters

Quality cost estimates is a key affordance of Clarity, and should be a factor when extending the language. There is an opportunity now to specify the slice function in a way that improves the ability to estimate execution cost: Make the function take the length of the slice as argument:

(slice "abcdefgh" index 2)  ;; return a subsequence of two characters

When the length is an integer constant, it is obviously trivial to determine the length of the output sequence, while the type inference can fall back on using the max length of the input sequence otherwise.

Additional context

• Original proposal: https://github.com/clarity-lang/reference/issues/42
• Issue https://github.com/stacks-network/stacks-blockchain/issues/3141

[kantai]

I think this is something close to syntactic-sugar for wrapping the call in as-max-length, right?

[njordhov]

Yes - and no. For the typical use cases in the original post, having the desired length as an argument to slice will enable type inference to trivially determine the return sequence length. In contrast, the current implementation with a right-position argument will introduce technical debt, making us stuck with wrapping such calls in as-max-length.

Hence, the slice function should take the length of the slice as argument instead of a right-position, allowing upcoming implementations to eliminate the need for it to be wrapped in as-max-length.

[jcnelson]

After much deliberation, the technical CAB voted to accept a slice implementation which took absolute left and right positions.

[njordhov]

After much deliberation, the technical CAB voted to accept a slice implementation which took absolute left and right positions.

@jcnelson This is blatantly false. As a member of the Technical CAB, I can confirm that we did not deliberate at all on the design and implementation of the slice function.

I am disappointed by the lack of substantial deliberation on this design choice and the insistence on the lesser of the options. It is one you'll have to take responsibility for yourself.