similar to: new bquote feature splice does not address a common LISP @ use case?

Hi Jan, In the lisp code you provide the operators are parsed as simple symbols in a pairlist. In the R snippet, they are parsed as left-associative binary operators of equal precedence. If you unquote a call in the right-hand side, you're artificially bypassing the left-associativity of these operators. To achieve what you're looking for in a general way, you'll need a more precise

Your example x = 5 exp = parse(text="f(uq(x)) + y +z") # expression: f(uq(x)) +y + z do_unquote(expr) # -> the language object f(5) + y + z could be done with the following wrapper for bquote my_do_unquote <- function(language, envir = parent.frame()) { if (is.expression(language)) { # bquote does not go into expressions, only calls

>After off list discussions with Jonathan Carrol and with >Michael Lawrence I think it's doable, unambiguous, >and even imo pretty intuitive for an "unquote" operator. For those of us who are not CS/Lisp mavens, what is an "unquote" operator? Can you expression quoting and unquoting in R syntax and show a few examples where is is useful, intuitive, and fits in to

Would this return a quosure? (i.e. a single sided formula that captures both expression and environment). That's the data structure we've adopted in tidyeval as it already has some built in support. Hadley On Friday, March 17, 2017, Michael Lawrence <lawrence.michael at gene.com> wrote: > Interesting idea. Lazy and non-standard evaluation is going to happen; the > language

Michael Lawrence (as last in long series of posters)... > Yes, it would bind the language object to the environment, like an > R-level promise (but "promise" of course refers specifically to just > _lazy_ evaluation). > > For the uqs() thing, expanding calls like that is somewhat orthogonal > to NSE. It would be nice in general to be able to write something like >

(please be gentle, it's my first time) I am interested in discussions (possibly reiterating past threads -- searching didn't turn up much) on the possibility of supporting standard evaluation unquoting at the language level. This has been brought up in a recent similar thread here [1] and on Twitter [2] where I proposed the following desired (in-principle) syntax f <-

I agree there is no reason they _need_ to be the same precedence, but I think SPECIALS are already have the proper precedence for both unary and binary calls. Namely higher than all the binary operators (except for `:`), but lower than the other unary operators. Even if we gave unary specials their own precedence I think it would end up in the same place. `%l%` <- function(x) tail(x, n =

I would like a function to strip quotes off character strings. I should work like this: > A <- matrix(1:6, nrow = 2, ncol=3) > AF <- as.data.frame(A) > names(AF) <- c("First","Second","Third") > AF First Second Third 1 1 3 5 2 2 4 6 > names(AF)[2] [1] "Second" > attach(AF) >

Changes from v2 to v3: - split_key_value_strings renamed to parse_key_value_strings Changes from v1 to v2: - split the "simple unquoting" as helper - pass the unquoting function to split_key_value_strings - use right unquoting function when applying split_key_value_strings Pino Toscano (2): daemon: add split_key_value_strings helper daemon: use parse_key_value_strings

Hi, Is this expected behavior (R-3.6.0)? dat <- cbind(x = 1:10, y = 10:1) ylab <- substitute(X[t], list(t = 2)) plot(dat, ylab = ylab) # works (correctly displays ylab) boxplot(dat, ylab = ylab) # fails boxplot(dat, ylab = as.expression(ylab)) # works Thanks & cheers, M

Hi list! An operation that I often need is splicing two vectors: > splice(1:3, 4:6) [1] 1 4 2 5 3 6 For numeric vectors I use this hack: splice <- function(x, y) { xy <- cbind(x, y) xy <- t(xy) dim(xy) <- length(x) * 2 return(xy) } So far, so good (?). But I also need splicing for factors and I tried this: splice <- function(x, y) { xy <-

The unquoting discussion is IMHO separate from this proposal and as you noted probably better served by a native operator with different precedence. I think the main benefit to providing user defined prefix operators is it allows package authors to experiment with operator ideas and gauge community interest. The current situation means any novel unary semantics either need to co-opt existing

Bill, Right. My example was the functional form for clarity. There is a desire for a unary-operator form. (rlang's !! and !!! operators described in the comments in the file I linked to). I can't really make that argument because I'm not one of the people who wanted that. You'd have to talk to the authors of the rlang package to find out their reasons for thinking that is

Martin, Jim can speak directly to his motivations; I don't claim to be able to do so. That said, I suspect this is related to a conversation on twitter about wanting an infix "unquote" operator in the context of the non-standard evaluation framework Hadley Wickham and Lionel Henry (and possibly others) are working on. They're currently using !!! and !! for things related to

I guess this would establish a separate "namespace" of symbolic prefix operators, %*% being an example in the infix case. So you could have stuff like %?%, but for non-symbolic (spelled out stuff like %foo%), it's hard to see the advantage vs. foo(x). Those examples you mention should probably be addressed (eventually) in the core language, and it looks like people are already able

I love the pointer analogy. Presumably the additional complication of scope breaks this however. * itself would have been a nice operator for this were it not prone to ambiguity (`a * *b` vs `a**b`, from which @ does not suffer). Would this extension require that function authors explicitly enable auto-quoting support? I somewhat envisioned functions seeing the resolved unquoted object (within

Hi All, The following patch set provides a low-overhead system for collecting kernel tracing data of guests by a host in a virtualization environment. A guest OS generally shares some devices with other guests or a host, so reasons of any problems occurring in a guest may be from other guests or a host. Then, to collect some tracing data of a number of guests and a host is needed when some

Hi All, The following patch set provides a low-overhead system for collecting kernel tracing data of guests by a host in a virtualization environment. A guest OS generally shares some devices with other guests or a host, so reasons of any problems occurring in a guest may be from other guests or a host. Then, to collect some tracing data of a number of guests and a host is needed when some

Hi LLVM developers, I have successfully installed LLVM 2.9 on an ubuntu linux box, with a LLVM-based frontend support of gcc and g++. After installing successfully vmkit I have tried running my java applications, but it failed. I have installed the latest stable release of vmkit (0.29) using the introduction text of the LLVM website. The application does consist of two programs. The first

? Sat, 17 Feb 2024 11:15:43 -0700 "Reed A. Cartwright" <racartwright at gmail.com> ?????: > I'm wrapping a function in R and I want to record all the arguments > passed to it, including default values and missing values. This is hard if not impossible to implement for the general case because the default arguments are evaluated in the environment of the function as it