« More R User Group Sites | Main | Bay Area useR Group Lightning Talks »

February 17, 2016


Feed You can follow this conversation by subscribing to the comment feed for this post.

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

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.

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.

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...

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.

|> .^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()

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.

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.

The comments to this entry are closed.

Search Revolutions Blog

Got comments or suggestions for the blog editor?
Email David Smith.
Follow revodavid on Twitter Follow David on Twitter: @revodavid