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

Implement applyl_at and applyr_at functions #208

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

redbaron
Copy link

@redbaron redbaron commented Feb 28, 2023

It adds applyl_at and applyr_at functions which apply single argument function to the nth HList element. It is implemented as a fold function which carries target and current depth levels as well as function application result in the accumulator.

Because n can be outside of the hlist length, function returns Option<_> with None returned if n is larger than list size.

It also hasapply*_args_at variants which adds args param to the accumulator to be passed to the function as a poor replacement for missing self (and therefore closure) param.

This is a draft PR to collect early feedback, more specifically:

  • is it something you'd like to see in this crate?
  • should it be standalone function like it is now or you prefer it to be a method on the HCons?
  • functions/arguments naming suggestions.

@redbaron
Copy link
Author

redbaron commented Mar 2, 2023

Added apply*_args_at variants

Copy link
Owner

@lloydmeta lloydmeta left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Out of curiosity, what is the use case for this?

In general, I'd like to avoid failable-at-runtime things in this crate because it feels like we could avoid them since we (should) know almost everything at compile time. For instance, we could use a Labelled Hlist, pluck out the element we want by type (we'd get a compile time error if it does not exist or is duplicated), then apply a function?

@redbaron
Copy link
Author

redbaron commented Mar 4, 2023

Not everyting is known at compile time. In my experiments I have a "query plan" (list of operations) in the HList and need to execute them in order when right conditions arise, hence the runtime n param to pick one to run.

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

Successfully merging this pull request may close these issues.

2 participants