spec multi-argument endpoint to ... operator
timo opened this issue · 4 comments
Hi,
I've encountered an example where I wanted to be able to express "stop the sequence when the last two elements were the same" and couldn't easily do that (although i have now forgotten what that was). It would look kind of like this:
1, 2, { #`( do some work ) } ... * == *
Edit: This may be problematic due to the smartmatching semantics that are the base for the end point; maybe it can be special-cased, though? Or should it be the same way closures inside array slices work, i.e. $length-of-list xx $number-of-closure-arguments
There have already been tests in roast that have multi-argument limit closures, but one of them assumes it would work to have a three-argument closure as the limit and not specify a starting list.
should it just generate unchecked until there are enough elements in the list to run the checking closure, or should we require the list to be pre-filled just like when we have a multi-argument generator closure?
since we can't generate any new values if we have insufficient elements for the generator closure, the limitation makes sense in that case. But we can generate enough values even if we can't check yet; maybe it should just delay the checking until there's enough elements.
Seems like we shouldn't check until we have enough values -- if the user wanted to check when there were fewer values than arguments for the limit closure, he should have used optional arguments, right?
right; i've been shown how niecza implements this and delaying the checking until enough values are available is the sanest solution.
on the way to merging this branch, i also fixed a bug where 1 ... { something } would create a decreasing sequence rather than the same way it works with 1 ... *.
Now all I have to do to close this bug is write it up in the spec :)