Displaying 20 results from an estimated 1000 matches similar to: "RFC: (in-principle) native unquoting for standard evaluation"
2017 Mar 19
3
RFC: (in-principle) native unquoting for standard evaluation
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
2017 Mar 17
2
RFC: (in-principle) native unquoting for standard evaluation
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
2017 Mar 19
0
RFC: (in-principle) native unquoting for standard evaluation
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
mean(x, extra_args...) without resorting to do.call(mean, c(list(x),
extra_args)). If we had
2017 Mar 17
0
RFC: (in-principle) native unquoting for standard evaluation
Interesting idea. Lazy and non-standard evaluation is going to happen; the
language needs a way to contain it.
I'll extend the proposal so that prefixing a formal argument with @ in
function() marks the argument as auto-quoting, so it arrives as a language
object without use of substitute(). Kind of like how '*' in C declares a
pointer and dereferences one.
subset <- function(x,
2017 Mar 19
3
RFC: (in-principle) native unquoting for standard evaluation
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
>
2017 Mar 19
0
RFC: (in-principle) native unquoting for standard evaluation
On Mon, Mar 20, 2017 at 7:36 AM, Radford Neal <radford at cs.toronto.edu> wrote:
> 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
2006 Aug 20
3
unquoting
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)
>
2017 Mar 17
2
Support for user defined unary functions
>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
2017 Mar 17
2
Support for user defined unary functions
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
2017 Mar 17
3
Support for user defined unary functions
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 =
2019 Feb 11
1
make.unique rbind examples
The final two examples in ?make.unique do not appear to be relevant to
that function, namely
rbind(data.frame(x = 1), data.frame(x = 2), data.frame(x = 3))
rbind(rbind(data.frame(x = 1), data.frame(x = 2)), data.frame(x = 3))
both producing
x
1 1
2 2
3 3
(identically) on R 3.4.3 and 3.5.1. Following a brief discussion on
Twitter, Rich FitzJohn [1] identified that under R 1.8.0 (circa 2003,
2020 Mar 17
3
new bquote feature splice does not address a common LISP @ use case?
Dear R-devel,
There is a new feature in R-devel, which explicitly refers to LISP @
operator for splicing.
> The backquote function bquote() has a new argument splice to enable splicing a computed list of values into an expression, like ,@ in LISP's backquote.
Although the most upvoted SO question asking for exactly LISP's @
functionality in R doesn't seems to be addressed by this
2017 Oct 16
3
[PATCH v3 0/2] daemon: add and use parse_key_value_strings helper
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
2017 Mar 17
2
Support for user defined unary functions
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
2017 Oct 16
3
[PATCH v2 0/2] daemon: add and use split_key_value_strings helper
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 split_key_value_strings
daemon/inspect_fs_unix.ml | 93 +++++++++++++++++++----------------------------
daemon/md.ml
2010 Nov 03
2
How to unquote string in R
s= "Hey"
a = "Hello"
table = rbind(s,a)
write.table(table,paste("blah",".PROPERTIES",sep = ""),row.names =
FALSE,col.names = FALSE)
In my table, how do I output only the words and not the words with the
quotations?
--
View this message in context: http://r.789695.n4.nabble.com/How-to-unquote-string-in-R-tp3025654p3025654.html
Sent from the R
2006 May 02
2
Mechanize and file_column
Hi all,
Has anyone successfully used WWW::Mechanize with file_column? I''m
trying to upload a bunch of images to a custom controller, and
something''s going wrong with the parameter names.
Using a noddy controller :create action that looks like this:
def create
render :text => params.inspect
end
I get this result from a manual upload from a form:
2006 Aug 02
1
loop, pipe connection, quote/unquote
Hi all,
I have the following problem.
Inside R, I am trying to run a loop on several files.
The data are stored in these files in a peculiar way, thus, at the same time I load the data, I would like to invoke a utility. I do this with "pipe". (The utility I am using is gbget from the package gbutils. It works correctly from shell, and it is not the problem.)
The problem is that from
2006 Nov 15
4
dyn.load (PR#9364)
Full_Name: Jonathan Tuke
Version: 2.4.0
OS: Mac OS X 10.4.8
Submission from: (NULL) (203.173.46.189)
I am writing C code to implement in R. I am using R CMD SHLIB and then
dyn.load("file.so"). The function I then call with .C("function"). Since I
installed the latest R version, I have found that if I alter my C code and
recompile, then use dyn.load("file.so"), the
2018 Jan 03
3
Coping with non-standard evaluation in R program analysis
Hello R experts,
I plan to develop a tool for dynamic analysis of R programs. I would like to trace function calls at runtime, capturing argument and return values. Following a suggestion made some time ago on this list, my high-level implementation strategy is to rewrite the AST, augmenting call expressions with pre-call and post-call shims to capture the arguments and return value,