Ellipsis is exposed through evaluation environment of functions

[sebffischer]

Currently, the ... is contained in the evaluation environment of functions:

> names((fn() environment())())
[1] "..."
> 

vs. R's behavior:

> names((function() environment())())
character(0)

[dgkf]

Although this is definitely a deviation from R, I sort of prefer it this way. It feels more transparent to me. For example, you can do this:

f <- function(...) { `...` }
f(a = 1 + 2, b = stop("test"))
#> $a
#> 1 + 2 @ <environment 0x120af4>
#>
#> $b
#> stop("test") @ <environment 0x120af4>

This transparency is more similar to python or julia's kwargs handling, where the object that is produced is a conventional language object.

If we really wanted to generalize, we could treat this just like ..rest (using --experiments rest-args), where this is just a convention of using ... (as in .. preceding ., providing a . variable that receives the rest of the args). Use of ... would just be a convention at that point.

You could still unpack it using ... (again, .. as an operator preceding a .) or access it directly in the variable ..

[sebffischer]

Yes, that makes sense! Maybe one can even generalize further to support, i.e. for parameters that are not of special ..args nature, the .. operator is a substitute (pun intended) for substitute() (but maybe I am missing some details here):

f = function(x) {
  ..x
}
f(1 + 2)
#> 1 + 2

Also, there seems to be a regression regarding --experiments rest-args, at least I cannot run the examples in the README for some reason.

[dgkf]

Yeah! I like that idea. It would be awesome to be able to splat an arbitrary list.

and sure enough, I’m seeing the same issue on the webapp: https://dgkf.github.io/R/?experiments=rest-args&expr=ZiA8LSBmdW5jdGlvbiguLnJlc3QpIHsKICAuLnJlc3QKfQoKZigxLDIsMyk

[dgkf]

Silly mistake on my part. This is not running into the same error, but does appear to be similar to the other issue regarding resolving returns:

f <- function(..x) {
  x  # _not_ `..x`
}
f(1 + 2)
#> [[1]]
#> 1 + 2 @ <environment 0x120b0c>

[dgkf]

Interestingly, this is currently broken in the terminal repl but not the webapp. The terminal evaluation throws out the experiments when choosing a parser whereas the wasm repl keeps them and does its own input validation.

---

edit: fixed in #142