Should map functions also work on environments?

[hadley]

Would either have to coerce to a list (which should be fairly cheap because only makes a shallow copy, but then the user could do that explicitly), or rewrite map_impl to use index by name rather than position (which would be a reasonable amount of work for a special case).

[lionel-]

that would be nice for expensive computations. It would enable us to recover the results on user interruption or when an error occured.

But for this use case we can't rely on the coercion-to-list trick.

[lionel-]

Then we can have map_env() where the output would always be an environment even on vector input.

Edit: Should it take env as argument? For the purpose of recovering the data on interruption. When env not supplied, create a new environment or, if the input is itself an env, use that one. If env is supplied, always write output there.

[hadley]

I'd want this to be idempotent, so it would either fail or succeed as a whole (i.e. it would alway create a new vector). We can currently handle errors with safely(), and we could potentially provide interrupt support using tryCatch() (but that make stack traces more complicated and gives potentially surprising behaviour)

[lionel-]

we could potentially provide interrupt support using tryCatch()

That would be nice. This is useful when doing simulations to check if we need more or if we already have enough to perform reasonable inferences.

Regarding the caveats you mention, we could provide separate functions such as safe_map(). Maybe we need a distinct particle though since that would not be the same as safely(). secure_map() or try_map() or something.

[lionel-]

otoh that may be a lot of work just to avoid a for loop. Im' thinking about this kind of pattern:

try_map(seq_len(nsims), draw_simulation)

[lionel-]

Could it be loop_map(), taking a number of loops as first arg and interruptible?

Edit: The map part would come from .f being passed the iteration number.
Edit2: And we could offer a loop() version where nothing except ... is passed to .f

[hadley]

@lionel- isn't that essentially rerun()?

[lionel-]

hmm yes, a standard evaluation version of rerun(). Also the _map version would pass i, and we could arrange for ~ lambda to pass .i instead of .x.

Or do you feel it's too redundant?

We could have both rerun() and loop() handle interruptions. Should we return an incomplete list in that case or a compacted one? I think the latter may be best because interruptions are for interactive use.

[hadley]

Re-reading this discussion I think we were slightly talking past each other. It seems like there's maybe to useful forms for mapping an environment:

• in place, where you don't return anything, but modify the environment passed in
• returning the result as a list

The second seems sufficiently different to the rest of the map functions to be worth a different name. It may also be more appropriate in rlang than purrr since it's no longer to do with vectors.

[hadley]

I'm going to close this since it feels a bit out of scope for purrr (which is mostly about lists/vectors).

It also just occurred to me that map_if(.x, ~ TRUE, .f) is now that modify in place verb, and following dplyr, maybe we should have map_all()?

[hadley]

And perhaps modify() would be a better name? I'll open an issue