How would you feel about an implementation like this?
Screenshot_20230420_120155.png
takeWhile
usually only returns the part of the list that it takes, right? this is more like a split
(which is still useful!)
I think this is the behaviour that is expected in the issue: https://github.com/roc-lang/roc/issues/5138
I agree though, it doesn't really match the name
maybe breakOn
?
Not sure about the Predicate
type itself though. I don't think it can be made anonymous.
I think that is too fancy, I don't think the predicate should be recursive
it would be more efficient to fold to find the index, and then slice, for instance
Folkert de Vries said:
it would be more efficient to fold to find the index, and then slice, for instance
I think the type I proposed still allows this sort of implementation
The recursive predicate allows you to make a decision using an arbitrart number of elements. I think this is the general case for what was described in the issue. Using a simple boolean predicate would not allow for making a decision based on two consecutive elements.
this is true, but would that be convenient to use in practice?
this makes me think of a fold, which is a traversal that keeps some state
In practice the type I proposed can be used as just a simple boolean predicate (Take and Break) without using NeedMore.
yes I understand, but is the inclusion of NeedMore
really worth it. it makes the signature more complicated
and its usecases can be covered in other ways
perhaps to resolve this: can you create an example that uses NeedMore
that might be included in the documentation?
I think we are actually debating if the function proposed in the Github issue is needed in builtins at all.
then let's see if we like that code
sure
yeah I think we should include the simpler (standard) version of takeWhile : List a, (a -> Bool) -> List a
and anything fancier than what that can do, can be done with List.walk
and variants, plus a List.splitAt : List a, Nat -> List a
makes sense to me!
Good discussion, thanks for clarification Folkert. I copied what I had into the issue, glad to see some design in here :smile:
To be clear: we decided to not implement takeWhile
as described in the Github issue, and instead decided to add a more traditional boolean-based takeWhile
?
yep!
Last updated: Jul 06 2025 at 12:14 UTC