-
Notifications
You must be signed in to change notification settings - Fork 166
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
Function list/find-maybe is a duplicate of list/foreach-while #583
Comments
Ha, good catch. Mm, I think it was done this way as I was considering having a different datatype for the
but I didn't follow up on this. It does feel a bit weird to look for an element in a list with
vs
not sure. |
Interesting. The What are your thoughts on having different isomorphic types in the core library, like Why do want to distinguish between isomorphic types at all? I think because we like to use this in domain modelling, such that code becomes more readable, and to make it more difficult to make mistakes related to mixing up values that conceptually represent different things. On the other hand, perhaps it's not a big deal, as long as there exist conversion functions between isomorphic types? |
This is probably different for everyone. For me that was a natural way of using it. I was looking through the module for an iteration function that would allow some form of conditionality, such that I could pick a first element that would satisfy a condition. Something with |
FWIW, I would say |
Yes, that is what I alluded to in the last sentence. But note that if |
It would be interesting to have functional inheritance as a feature of datatypes. i.e.
Essentially the idea is, first implicit resolution attempts to find based on while, and then if it cannot find it, also tries maybe using the implicit coercion. Coercions could be automatically generated for isomorphic types (by request). |
I think we can remove find-maybe from the standard library?
The text was updated successfully, but these errors were encountered: