New syntax proposed for R language

R user and developer Lionel Henry proposes a number of changes to R syntax:

Use square brackets to create lists. You could use [1, 2:5, "hello"] to create a list of three elements. Nested lists would be possible as well, with syntax like or [ [1, 2], [2, 3] ] (much easier than list(list(1,2),list(2,3))).

Define lambda functions with square brackets. You could create an unnamed function like [x] -> log(abs(x)) to transform x to the log of its positive part. This is a little easier than using calling function(x) log(abs(x)) .

Allow labeled blocks. This change would make it easier to pass blocks of code into functions. You could write:
test_that("my code works") {
  check_equal(A,B)
  check_identical(C, D)
}
instead of
test_that("my code works", {
 check_equal(A,B)
 check_identical(C, D)
})
It would also allow you to create your own functions that have similar syntax (like a custom if statement).

A native piping operator. Magrittr's %>% pipe operator would get a new look, so that mtcars |> unlist would be a standard part of the language. This would also make it easier to debug code that used the pipe.

R is a very flexible language that provides many native facilities to extend the language itself. The %>% operator is defined as a "special operator" in the magrittr package, and you can even define Haskell-like list comprehensions for R by redefining the [ operator yourself. That approach won't work Lionel's changes above, though: because they modify R syntax they need to be made at the R source code level. (You can find Lionel's changes in this fork of the R source tree on GitHub.) That means it's fairly unlikely they'll be incorporated by R Core (not least because of the potential for backwards compatibility issues) but you never know.

You can read Lionel's full description of his proposed changes at the blog post linked below. His post doesn't have a comments section, so let us know what you think of the changes in the comments here.

(routines ...): The future of R syntax?

Comments

[Robin]

Fully agree with square bracket lists and pipe operator (maybe like "|>").

[Aleksey Zemnitskiy]

I don't know if the lambda-friendly syntax would be easy to get absorbed at this point, but a decent threading model for the R language would be a great improvement indeed. Until then, R would be slowly loosing user base to general purpose languages like Python, which do not limit you to OpenMP for multicore processing.

[Kevin Wright]

The R language is already difficult to read, especially for beginners. Every single non-alphanum character on the keyboard has a meaning in R, as do many combinations of characters like .( && %>% etc. Continuing to define ever more esoteric symbols will only increase the alphabet zoo of symbols and make the language even more hard to read. Sure, it saves a few strokes of typing, but Clarity trumps Beauty. One of R's strengths is organic growth over time. But, one of R's weaknesses is organic growth over time that gives the language a hodgepodge of syntax as opposed to a very beautiful and consistent syntax in a language like Wolfram.

[Rasmus Bååth]

Completely reasonable changes to me (but I almost proposed the same myself http://www.sumsar.net/blog/2013/12/three-syntax-addtions-that-would-make-r/). :) However, I also have 110% respect and understanding for why R-core would not want to change any syntax. A syntax change is a big thing...

[Stefan Fritsch]

1. The pipe operator is a must. Period. I'd also expect a <|> Operator as analogue to %<>% and |$> for %$%.

2. Please make R locale independent, pretty please. Keeping encodings on Windows or Unix with non-UTF8 locales is an exercise in frustration.

3. A concise syntax for lists would be nice but I'm not 100% convinced that yet another overload of brackets is a good idea.

Why not just create a standard function called l to mirror c:

l(1, 2, l(3,4))

Even though that will get confusing for people who use fonts with similar 1 and l. Perhaps p as a tribute to pairlists?

4. It would be nice if - like "else" - the parser would allow the pipe at the beginning of a new line.

input
|> .^2
|> sqrt

5. I'm a mathematician so IMHO . is a better placeholder than _. :)

6. I like magrittr's lambdas. You could allow multiple arguments by overloading the placeholder with a function-form:

.(a,b) |> .$a + .$b
.(a,b) |$> a + b

Or use .() as a short form of function()

[Carl Witthoft]

The use of "." for multiple purposes is fraught with risk. My standard example is MATLAB's use of "." to indicate non-matrix operations. If you have MATLAB or the equivalent, try this:
> x = reshape(1:4,2,2);
> y = reshape(5:8,2,2);
> x * 2.0/y
> x * 2./y

Currently R has three uses for "." : decimal point in numerics, function names (ideally only for specifying a method), and as a "hold-all" in formulas. I would recommend against adding more possibilities.

[Stefan Fritsch]

But it's just the continuation of its use as catch all in formulas.

There is also no danger of confusing the decimal point and the other options as everything else has to be syntactically separated from numbers.

And the dot in names is not really a counter-argument as most candidates for placeholders are valid in names. E.g. the _ is heavily pushed in the hadleyverse.