Should is_list return TRUE for pairlists?

[hongooi73]

Because if it doesn't, you can't splice them. This makes it difficult to build lists of expressions for feeding to invoke and/or do.call.

For example:

f <- function(extra)
{
    expr <- enexpr(extra)
    l <- list(a=1)
    g(l, expr)
}

## this works, using base R
g <- function(l, expr) c(l, lang_tail(expr))

f(list(b=2, c=3))
#$a
#[1] 1

#$b
#[1] 2

#$c
#[1] 3


## this doesn't work, because lang_tail(expr) is a pairlist, not a list
g <- function(l, expr) modify(l, splice(lang_tail(expr)))

f(list(b=2, c=3))
#Error: Only lists can be spliced

[lionel-]

It really shouldn't because those are very different data structures.

this doesn't work, because lang_tail(expr) is a pairlist, not a list

You can use lang_args() to get the arguments as a list instead. Note that you'll be converting from a pairlist to a list then back to a pairlist. The first conversion incurs one allocation but the second incurs many.

[lionel-]

The first conversion incurs one allocation but the second incurs many

of course most of the time this doesn't matter ;)

[hongooi73]

Cools, I was doing splice(as.list(lang_tails(*, which I see is what lang_args does. Thanks.

[lionel-]

just out of curiosity, why are you using splice() instead of !!!? Do you find the functional form easier to read?

[hongooi73]

Heh. One of the things that I tell people is nice about R compared to SAS, is that you don't have to program via macros. No need for ampersands, percents and dots cluttering up your code. So it's ironic to see this design coming back into R.

[lionel-]

That's not a macro, it's evaluated at run time and works on runtime values.That's more like an syntactic operator, and R has many of them.

If you don't want syntax, lisp is a better choice than R. But even lisp has syntax for unquoting and splicing, because it's normally much easier to reason about these operations syntactically.

[lionel-]

On the other hand I agree that the behaviour of quo(c(!!! args)) does look like an expansion step and is macro-like in that sense. But that behaviour is identical with the functional form: quo(c(UQS(args))).

[hongooi73]

This is about the syntax. Here's an example SAS macro (https://support.sas.com/documentation/onlinedoc/91pdf/sasdoc_91/base_macro_6997.pdf)

%macro splitit;
    %put What character separates the values?;
    %input;
    %let s=%bquote(&sysbuffr);
    %put Enter three values.;
    %input;

    %local i;
    %do i=1 %to 3;
        %global x&i;
        %let x&i=%qscan(%superq(sysbuffr),&i,&s);
    %end;
%mend splitit;

%splitit
What character separates the values?
#
Enter three values.
Fischer Books#Smith&Sons#Sarah’s Sweet Shoppe

Notice the proliferation of punctuation. I'm not a fan of introducing more punctuation into R, especially if you have to override the regular parser to do it.

That said, I do think this new paradigm is much easier to work with than the previous dplyr method of foo_ methods for programming. It's made my dplyrXdf code a lot simpler, for example.

[lionel-]

In general I agree with you, but in the case of quasiquotation the semantics are so peculiar that it deserves special syntax to help reason about code. I think the fact that even lisps have syntax for quasiquotation is telling that it's the right way. Of course it's also a matter of taste, so we provided the functional form as well.

[vspinu]

@lionel- does the "Details" of splice elaborate on relationship between splice and !!!? It's rather cryptic.

[lionel-]

oops I think we didn't update the documentation of tidy dots for the 0.2.0 release. @hadley probably worth to include this in the release?

[hadley]

Yes please