-
Notifications
You must be signed in to change notification settings - Fork 659
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Clarity] Slice n items from sequence #3149
Comments
I think this is something close to syntactic-sugar for wrapping the call in |
Yes - and no. For the typical use cases in the original post, having the desired length as an argument to Hence, the |
After much deliberation, the technical CAB voted to accept a |
@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 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. |
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 atright-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: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: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
slice
result doesn't change length on buffer type #3141The text was updated successfully, but these errors were encountered: