Better display for list columns if all elements have the same type about pillar

[hadley]

One idea: if every element has the same "type", display that in the header, and then display the dimension in each row.

[krlmlr]

We now have this in the PR:

pillar::pillar(vctrs::list_of(1:3))
#> <list<int>>
#>     1, 2, 3

^{Created on 2019-05-03 by the reprex package (v0.2.1)}

[krlmlr]

And this with r-lib/vctrs#317:

pillar::pillar(vctrs::list_of(1:3, 4:100))
#> <list<int>>
#>         [3]
#>        [97]

^{Created on 2019-05-03 by the reprex package (v0.2.1)}

[krlmlr]

We should also think about coloring list columns blue or green (#23 (comment)).

[wlandau]

For lists of symbols and language objects, it would be awesome to see the expr_text() of each element instead of <symbol> or <language>. One use case is drake::map_plan(), which accepts a data frame of function arguments.

library(tidyverse)
args <- expand.grid(
  data = c("simulated", "robinson_et_al", "smyth_et_al"),
  method = c("bayesian", "frequentist"),
  stringsAsFactors = FALSE
) %>%
  mutate(data = rlang::syms(data)) %>%
  as_tibble() %>%
  print()
#> # A tibble: 6 x 2
#>   data     method     
#>   <list>   <chr>      
#> 1 <symbol> bayesian   
#> 2 <symbol> bayesian   
#> 3 <symbol> bayesian   
#> 4 <symbol> frequentist
#> 5 <symbol> frequentist
#> 6 <symbol> frequentist

In map_plan(), characters get quotes and symbols do not. The distinction is extremely useful.

drake::map_plan(args, analyze)
#> # A tibble: 6 x 2
#>   target           command                                                
#>   <chr>            <chr>                                                  
#> 1 analyze_34dedc26 "analyze(data = simulated, method = \"bayesian\")"     
#> 2 analyze_bc3d5587 "analyze(data = robinson_et_al, method = \"bayesian\")"
#> 3 analyze_524f3aca "analyze(data = smyth_et_al, method = \"bayesian\")"   
#> 4 analyze_48fb9d8b "analyze(data = simulated, method = \"frequentist\")"  
#> 5 analyze_ee37695c "analyze(data = robinson_et_al, method = \"frequentist…
#> 6 analyze_70ba84cd "analyze(data = smyth_et_al, method = \"frequentist\")"

The command column of a drake plan can be a list of language objects rather than a character vector, and I may make language objects the default at some point. One minor source of friction is the printing.

plan %>%
  mutate(command = purrr::map(command, rlang::parse_expr)) %>%
  print()
#> # A tibble: 6 x 2
#>   target           command   
#>   <chr>            <list>    
#> 1 analyze_34dedc26 <language>
#> 2 analyze_bc3d5587 <language>
#> 3 analyze_524f3aca <language>
#> 4 analyze_48fb9d8b <language>
#> 5 analyze_ee37695c <language>
#> 6 analyze_70ba84cd <language>

I do realize that I can customize printing within a column, but I thought I would ask about the default first. I am not aware of a situation in which a column of <language> indicators is preferred.

[wlandau]

What are your current plans for this issue? I do not mean to rush anything, I am just asking because the priority and timing will affect how I solve it could improve the existing solution to ropensci/drake#700.

ropensci/drake#700 (comment) (using ropensci/drake@fa96707) is an example of what I am looking for. Without custom S3 magic, the command column would print as a <list> of <language>s.

[wlandau]

I am still having trouble printing tibbles that contain lists of language objects. Should I open an issue in vctrs? Is this within scope?

utils::packageDescription("pillar")$RemoteSha
#> [1] "072fe73e660e8a891f1fbe08607eb60a190444f5"
utils::packageDescription("vctrs")$RemoteSha
#> [1] "25d8607960881c74d1d9272eb71580140311c00d"
tibble::tibble(x = list(quote(foo <- 0L)))
#> # A tibble: 1 x 1
#>   x         
#>   <list>    
#> 1 <language>
tibble::tibble(x = vctrs::list_of(quote(foo <- 0L)))
#> `list(...)[[1]]` must be a vector, not a call
vctrs::list_of(quote(foo <- 0L))
#> `list(...)[[1]]` must be a vector, not a call

^{Created on 2019-05-05 by the reprex package (v0.2.1)}

[krlmlr]

Yes please -- we can't do anything here.

[github-actions]

This old thread has been automatically locked. If you think you have found something related to this, please open a new issue and link to this old issue if necessary.