A decision needs to be made regarding the syntax allotalot will use.

The original syntax used a . function to produce the name structure on the left-hand side of the assignment expression,

.(a, b) %<-% list(0, 1)
.(a, .(b, c)) %<-% list(0, list(1, 2))

The new syntax uses :'s as a means of listing bare names and {'s as a means of nesting names,

a: b %<-% list(0, 1)
{a: b} %<-% list(0, 1)

a: {b: c} %<-% list(0, list(1, 2))
{a: {b: c}} %<-% list(0, list(1, 2))

The new syntax is thought of as lighter and thus a better option than the original syntax. However, if the new syntax obfuscates assignment expressions the original syntax will be used. If neither syntax is clear enough, a new, third, syntax may be proposed.

A couple sections still allude to the old curly braces syntax.

See following examples,

c(a, ...b = list()) %<-% c(1)
# b = list() ? Nope, NULL

c(d, ...e = list(2)) %<-% c(1)
# e = list(2) ? Nope, 2

We would expect both a and d to have a value of 1 and they do. However, b has a NULL value and e has a value of 2. The pair_off variable needs to indicate that a collector variable has a default. Alternatively, collector variable handling needs to be moved out of the multi_assign function and get moved to the pair_off function.

The master branch of this repository will soon be renamed to main, as part of a coordinated change across several GitHub organizations (including, but not limited to: tidyverse, r-lib, tidymodels, and sol-eng). We anticipate this will happen by the end of September 2021.

That will be preceded by a release of the usethis package, which will gain some functionality around detecting and adapting to a renamed default branch. There will also be a blog post at the time of this master --> main change.

The purpose of this issue is to:

• Help us firm up the list of targetted repositories
• Make sure all maintainers are aware of what's coming
• Give us an issue to close when the job is done
• Give us a place to put advice for collaborators re: how to adapt

message id: euphoric_snowdog

In one month's time remove old syntax, pull changes from error-clean-up branch, bump version to 0.0.5, and submit to CRAN again.

The tests file for the assignment operator extensively tests the function. But! since the file is long, writing a second test file to outline and test the expected usage and result of %<-% would be quite useful.

• update code chunks
• update existing sections
• add new section highlighting the syntax

While the code chunks in the introductory vignette have been updated and use the new syntax, the existing sections still reference . and need fixing. Adding a section to highlight and explain the new syntax is also necessary.

e.g.

library(zeallot)

{1} %<-% list(1)
{f()} %<-% list(1)

Why does data frame need a method? That seems weird to me (especially since the default method throws an error - how do regular lists get handled?)

####Neither the README nor unpacking assignment vignette make it explicit you can use %<-% to assign different types in one expression. I ran the following experiment and it appears to be the case.

library(zeallot)

c(a, b, c, d, e) %<-% list(1.0, 1L, "1", factor(1), data.frame(x = 1))
lapply(list(a = a, b = b, c = c, d = d, e = e), class)
#> $a
#> [1] "numeric"
#> 
#> $b
#> [1] "integer"
#> 
#> $c
#> [1] "character"
#> 
#> $d
#> [1] "factor"
#> 
#> $e
#> [1]  #"data.frame"

Is this expected behavior for how %<-% operates? If so, it should be made more clear.

I've seen a number of people mention the verbose traceback when using %<-%. Using rlang's trace_back() would cut down on spurious calls by adjusting the bottom of the trace.

There are a couple tests which check if the old syntax is still caught. These need to be removed as the old syntax is being phased out.

How does Python handle the following,

a, [b, c] = [1, [[], 2]

There's a small typo in the final example code snippet. The <- needs to be %<-%.

Since %<-% is also used by future and the usage of namespaces with operators is a little messy zeallot::%<-%(c(a, b), c(1, 2)) to differentiate between the different overrides of the operator, could a second alternative variation be created. It's a really useful operator, adding one of the pieces of functionality that r misses vs python. For my own use I've cloned and changed the operator to %<-c%, but I guess anything would work.

In the original syntax, .. is used to skip values on the right-hand side of an assignment expression. In the new syntax a single dot . will be used instead.

> c(...x, y) %<-% list(3)
Error: invalid `%<-%` right-hand side, incorrect number of values

Can we have a feature where x can be empty?

Add %->% operator.

c(1, 2) %->% c(x, y)

Currently magrittr chains must be wrapped in parentheses, see issue tidyverse/magrittr#137.

c(x, ...rest) %<-% (
  1:5 %>%
  lapply(function(i) i + 5)
)

A right operator would allow us to drop the parentheses and give the chain a cleaner look.

1:5 %>%
  lapply(function(i) i + 5) %->%
  c(x, ...rest)

I discovered this large mistake last week. The version of zeallot formally supporting R 3.1 was never uploaded to CRAN.

A thought: Instead of %<-%, how about %<=%?

Advantages:

• the two strokes in = (versus single stroke in -) visually reflects the notion of multiple (versus single) assignment
• won't conflict with the implicit-future construct in the future package

(Could %<=% introduce a worse clash than that with future::`%<-%`?)

This basically just requires adding this to your travis:

r:
- 3.1
- 3.2
- oldrel
- release
- devel

And this to DESCRIPTION:

Depends:
    R (>= 3.1)

And then fixing any small issues that arise.

Then I would feel confident about re-exporting %<-% from purrr.

The latest commit doesn't catch the following case,

a: b %<-% c(1, 2)

Errors from massign are raised instead.

See tidyverse/magrittr#137

Would it be possible to make %<-% work with %>% chains on the left hand side?

In Javascript we can do:

var o = {p: 42, q: true};
var {p: foo, q: bar} = o;
 
console.log(foo); // 42 
console.log(bar); // true

let {a, b, ...rest} = {a: 10, b: 20, c: 30, d: 40}
a; // 10 
b; // 20 
rest; // { c: 30, d: 40 }

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment#Object_destructuring

I realize that in R, while named list resembles a hash map, it is indeed ordered.

Maybe something like this?

list(a, b) %<-% list(b = 2, a = 1)
# a = 1 
# b = 2

unpacking may not currently work for atomic vectors of length greater than 1

unpack may need modification

Run the following example and you will find that traceback() is pretty unhelpful.

library(zeallot)
c(foo, bar) %<-% list(log("foo"), "bar")
traceback()

Explore ways to make this better, if possible.

Maybe something like this:

{x : ... : y } %<-% list(1, 2, 3, 4, 5)
{x : . : y : . : z} %<-% list(1, 2, 3, 4, 5)

e.g.

• https://github.com/crowding/vadr/blob/master/R/bind.R
• https://stackoverflow.com/questions/7519790/assign-multiple-new-variables-on-lhs-in-a-single-line-in-r

You might also want to mention that this operation is commonly known as a destructuring bind.

I think c(a, b, c) <- f() would be a nice alternative to {a : b : c} <- f().

I really like this example from the vignette:

mtcars %>%
  subset(hp > 100) %>%
  aggregate(. ~ cyl, data = ., FUN = . %>% mean() %>% round(2)) %>%
  transform(kpl = mpg %>% multiply_by(0.4251)) %->% 
  c(cyl, mpg, ...rest)

But I think it would be cool, readable, and writable if we could do something like this:

mtcars %>%
  subset(hp > 100) %>%
  aggregate(. ~ cyl, data = ., FUN = . %>% mean() %>% round(2)) %>%
  transform(kpl = mpg %>% multiply_by(0.4251)) %>% 
  unpack(cyl, mpg, ...rest)

When collecting values from a vector, the collected values are returned as a list.

a: ...rest %<-% 1:5
a
#> 1
rest
#> list(2, 3, 4, 5)

I would expect rest to equal 2:5, but currently rest is assigned list(2, 3, 4, 5).

Which would work like combination of head and tail - would be a good demo

What do you think of an operator that's a combination of magritter::`%<>%` and zeallot::`%<-%`

example usage might be

x <- letters[1:4]
y <-  c("w", "x", "y", "z")
f <- c(1,1,2,2)

c(x, y) %<->% lapply(z, function(z) split(z, f))

I'm imagining that the operator would take the left hand side c(x,y) and behind the scenes would call list(x = x, y = y) and pass that list as the first argument to the right hand side function as ., with standard magrittr rules for . placement and evaluation.

list from the gsubfn package supports assigning only some return values while dropping others:

# assign Green and Blue (but not Red) components
list[ , Green, Blue]  <- col2rgb("aquamarine")

Can such functionality be implemented in zeallot as well?

As a work-around, I can assign unused return arguments to dummy variables. But as direct assignment of multiple return values is syntactic sugar, I would prefer as sweet a syntax as possible for the price of non-standard assignment and the extra package dependency.

Regards
Christian

The rest prefix will allow a variable to consume part of the list of values. In the example below "..." is used to consume the remaining elements of the list,

a: ...b %<-% list(1, 2, 3, 4, 5)
a  # 1
b  # list(2, 3, 4, 5)

The rest prefix may also be used to consume a portion of values,

a: ...b: c %<-% list(1, 2, 3, 4, 5)
a  # 1
b  # list(2, 3, 4)
c  # 5

Great package, I've missed this a lot after python/haskell.

Just tried something crazy and found it didn't work:

l <- some_existing_list
c(l$a, l$b, l$c) %<-% some_func(x, y)

But it would be nice to be able to assign to absolutely anything on the left hand side without using intermediary variables, no idea how hard that is to implement!

The readme under the getting started section contains a reference to the old bracket and colon notation.

For consistency

First of all, I really love zeallot! Simple, basic, coherent, very useful.

However, during debugging in e.g. RStudio I often step through code and step into functions, which is easily done just pressing Alt+F4. However, if I want to step into function f below I enter into a bunch of tryCatch statement and it is very hard to reach into f(x).

c(a, b) %<-% f(x)

Would it be possible to simplify the function chain so that one quickly enters the internals of f(x)? Or another way that I can enter into f(x)? I would prefer not having to stop the program, enter a browser() statement and rerun, as I often do now when debugging my Shiny app.

when using zeallot, package can't pass CRAN check:

c(d_fit, info_peak) %<-% rough_fitting(INPUT)

# checking R code for possible problems ... NOTE
opt_season: no visible binding for global variable 'd_fit'
opt_season: no visible binding for global variable 'info_peak'

Undefined global functions or variables:
d_fit info_peak

Any suggestions?

The first example of the vignette
c(lat, lng) %<-% list(38.061944, -122.643889)
returns
Erreur : unexpected call c
I'm using MacOS X Sierra and R version 3.3.3 (same error with 3.3.2)

Something like this:

assign all dataframe column as variables to the current environment
c(!!! names(mtcars)) %<-% mtcars

Nice package, thanks for bringing multiple assignments into R I like that feature of python.

I have read this issue thomasp85/patchwork#32, and I tried to create a plot and then use multiple assignments to reorder the appearance using the mentioned package. However %<-% couldn't would it be possible to work like this:

c(setosa, versicolor, virginica) %<-% ggplot(iris) + 
    geom_point(aes(Sepal.Length, Sepal.Width)) + 
    facet_wrap(~Species)
Error: invalid `%<-%` right-hand side, incorrect number of values

Maybe the issue is how to handle gg and ggplot classes, but I am not enough familiar with gg classes to propose a solution (or to know if it is feasable).

Again thanks
(I was using the version of zeallot from CRAN, zeallot_0.1.0 ggplot2_2.2.1)

It would be nice to get multi assign in for loops also (similar to tuple unpacking in python). Here is a mockup implementation. The syntax of this is kinda clunky, it would be nicer if it better mirrored the semantics of an actual R for loop, but that will require greater R jedi skills than I currently posses.

library(zeallot)
pfor <- function(loop_construct, expr) {
  loop_construct <- substitute(loop_construct)
  expr <- substitute(expr)
  loop_list <- eval(loop_construct[[3]], parent.frame())
  for(i in seq_along(loop_list)) {
    loop_construct[[3]] <- loop_list[[i]]
    eval(loop_construct, envir = parent.frame())
    eval(expr, envir = parent.frame())
  }
}

pfor (c(a, b) %<-% list(list(1, 2), list(3, 4)),
  print(c(a, b)))
#> [1] 1 2
#> [1] 3 4

Created on 2018-02-22 by the reprex package (v0.2.0).

See JS example here https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment#Default_values_2

@pteetor , right now the following syntax throws an error,

{a : ...b} %<-% list(1)
#> Error: cannot de-structure numeric 

Would assigning list() to b instead of throwing a be a benefit?

The syntax would then work as follows,

{a : ...b} %<-% list(1)
a
#> 1
b
#> list()

Off the top of my head I could see this proving useful for base cases.

WHILE this, rest %<-% CALL() {
    IF rest IS EMPTY {
        // base case
    }
    // else case
}

Safe functions in purrr suggest this syntax is unnecessary because the programmer never has to worry about only getting one value back. There are always two values returned, but one is NULL. A secondary vignette outlining how to write functions with the %<-% operator in mind might be better than adjusting the syntax.

Came up during this example,

library(rlang)
c(expr, env) %<-% quo(foo)

I expect an error, but the warning is not expected and is a bug. The is_list() util should check that the first (and only?) class is "list".

Example

`:=` <- zeallot::`%<-%`

c(a, b) := c("this", "that")

a
# [1] "this"
b
# [1] "that"

There is no right-hand equivalent, but the := is a valid infix operator and would save a bit of typing. As an example, packages rlang and data.table export their own defined := infix operator.