Skip to content
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

Question about ascertaining which fields are undefined #8

Open
bbarker opened this issue Jan 8, 2021 · 2 comments
Open

Question about ascertaining which fields are undefined #8

bbarker opened this issue Jan 8, 2021 · 2 comments

Comments

@bbarker
Copy link

bbarker commented Jan 8, 2021

It would be somewhat useful for certain applications to see which Opt fields of a nested record are undefined. My example is I'd like to use something like this for the ViewModel in an application, where I have an extended View Model with Opt values, based on a Record type without any Opt values that represents just the "Model". To give feedback to the user, it would be great to be able to query which Opt fields are still undefined.

Is this something that might be doable?

Thanks,

@paluh
Copy link
Owner

paluh commented Jan 12, 2021

Hi @bbarker!

Would you be so kind and tell me if you have any suggestion what should be the type (in "pseudcode" ;-)) of this function? I've done some investigation regarding homogeneous records (which surprisingly maybe can be useful here) and I'm doing recursive traversing in this lib so maybe I can try to help.

@bbarker
Copy link
Author

bbarker commented Jan 13, 2021

Hi @paluh , thanks for the reply.

I'll try to add more pseudocode and some more description.

fromOpt: TOpt -> Either String T, where TOpt, T are record types related by the fact that for some fields of T', say fieldX, we have the following relationship:

fieldX: Opt X -- in TOpt
fieldX: X -- in Opt

But what if instead we have a relationship like:

fieldX: Opt XOpt -- in TOpt
fieldX: X -- in Opt

That is, XOpt and X have the same relationship as TOpt and T above. In this case, ideally fromOpt would work in a recursive fashion, extracting the Opts in an Either monad, and at the first failure, return the name of the field (or alternatively, the complete record hierarchy of the path if that is doable, or alternatively against, instead returning a String as the Left value, some collection of strings could be returned if it is relatively easy to return all missing fields - though depending on the use case, some may prefer to return on just the first failure).

The tricky part (well, there are probably several tricky parts) to me is that in the recursive case, what if XOpt has Opt fields that we don't want to keep? If they are X as type Opt _, we can pass them through unchanged, and if they are not in X at all, we ignore them and do not return them in the resultant X value. So, maybe that part isn't as tricky as I first thought.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants