similar to: RFC: getifexists() {was [Bug 16065] "exists" ...}

If we do add an argument to get(), then it should be named consistently with the ifnotfound argument of mget(). As mentioned, the possibility of a NULL value is problematic. One solution is a sentinel value that indicates an unbound value (like R_UnboundValue). But another idea (and one pretty similar to John's) is to follow the SYMSXP design at the C level, where there is a structure that

On Thu, Jan 8, 2015 at 11:57 AM, <luke-tierney at uiowa.edu> wrote: > On Thu, 8 Jan 2015, Michael Lawrence wrote: > > If we do add an argument to get(), then it should be named consistently >> with the ifnotfound argument of mget(). As mentioned, the possibility of a >> NULL value is problematic. One solution is a sentinel value that indicates >> an unbound value

Adding an optional argument to get (and mget) like val <- get(name, where, ..., value.if.not.found=NULL ) (*) would be useful for many. HOWEVER, it is possible that there could be some confusion here: (*) can give a NULL because either x exists and has value NULL, or because x doesn't exist. If that matters, the user would need to be careful about specifying a value.if.not.found

On 08/01/2015 9:03 AM, John Nolan wrote: > Adding an optional argument to get (and mget) like > > val <- get(name, where, ..., value.if.not.found=NULL ) (*) That would be a bad idea, as it would change behaviour of existing uses of get(). What I suggested would not give a default. If the arg was missing, we'd get the old behaviour, if the arg was present, we'd use it.

On Thu, 8 Jan 2015, Michael Lawrence wrote: > If we do add an argument to get(), then it should be named consistently > with the ifnotfound argument of mget(). As mentioned, the possibility of a > NULL value is problematic. One solution is a sentinel value that indicates > an unbound value (like R_UnboundValue). A null default is fine -- it's a default; if it isn't right for

> Adding an optional argument to get (and mget) like > val <- get(name, where, ..., value.if.not.found=NULL ) (*) > would be useful for many. HOWEVER, it is possible that there could be > some confusion here: (*) can give a NULL because either x exists and > has value NULL, or because x doesn't exist. If that matters, the user > would need to be careful about

>>>>> Martin Maechler <maechler at stat.math.ethz.ch> >>>>> on Fri, 9 Jan 2015 14:00:38 +0100 writes: >>>>> Michael Lawrence <lawrence.michael at gene.com> >>>>> on Thu, 8 Jan 2015 14:02:26 -0800 writes: >> On Thu, Jan 8, 2015 at 11:57 AM, <luke-tierney at uiowa.edu> wrote: >>> On Thu, 8

>>>>> Michael Lawrence <lawrence.michael at gene.com> >>>>> on Thu, 8 Jan 2015 14:02:26 -0800 writes: > On Thu, Jan 8, 2015 at 11:57 AM, <luke-tierney at uiowa.edu> wrote: >> On Thu, 8 Jan 2015, Michael Lawrence wrote: >> >> If we do add an argument to get(), then it should be named consistently >>>

Dear all, I have noticed that the expression 'list =' is sometimes used to tell R to evaluate something before executing it. Two examples: rm(list=ls()) a = 3 myVarName = 'a' save(list=myVarName, file=...) I was wondering whether there is any documentation on this way of using "list". Which is a clearly different use than what ?list talks about, as the latter

I argue we should spell C++ lambdas (and other function-like variables) like functions, not like variables. - Use verbs, not nouns. - Use lowerCamelCase. Here's a patch that implements the change to the coding standards: https://reviews.llvm.org/D48991 <https://reviews.llvm.org/D48991> Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi LLVM, If I have an llvm value "<16 x float> addrspace(1)* %in", and in the LLVM IR, there is a @llvm.dbg.value like: call void @llvm.dbg.value(metadata <16 x float> addrspace(1)* %in, i64 0, metadata !216, metadata !28), !dbg !217 How I can retrieve this @llvm.dbg.value when I have "%in"? Since Metadata is not a part of the uselist anymore, is there some way

> On Jul 5, 2018, at 1:09 PM, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> On Thu, Jul 5, 2018 at 12:57 PM Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: >> I argue we should spell C++ lambdas (and other function-like variables) like functions, not like variables. >> >> - Use verbs, not nouns. > > I think I agree with

TL;DR: change the rule for variable names from UpperCamelCase to lowerCamelCase. Just to get wider visibility on this, I'm raising this again as an RFC, as suggested by Roman Lebedev. My original post from last week is here and gives a rationale: http://lists.llvm.org/pipermail/llvm-dev/2019-February/129854.html. There seemed to be general agreement that the status quo is not ideal.

> On Jul. 5, 2018, at 18:12, Bruce Hoult via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Thu, Jul 5, 2018 at 5:30 PM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > On Jul 5, 2018, at 1:09 PM, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at

On Tue, Oct 13, 2015 at 4:43 PM, Hadley Wickham <h.wickham at gmail.com> wrote: > Seems easy enough to write yourself: > > where <- function(x, env = parent.frame()) { > if (identical(env, emptyenv())) > return(NULL) > if (exists(x, envir = env, inherits = FALSE)) > return(env) > where(x, parent.env(env)) > } > > sample2 <-

Hi All, I've been looking into speeding up the loading of packages that use a lot of S4. After profiling I noticed the "exists" function accounts for a surprising fraction of the time. I have some thoughts about speeding up exists (below). More to the point of this post, Martin M?chler noted that 'exists' and 'get' are often used in conjunction. Both functions are

Thanks Winston! I'm amazed that "[[" beats calling the .Internal directly. I guess the difference between .Primitive vs. .Internal is pretty significant for things on this time scale. NULL meaning NULL and NULL meaning undefined would lead to the same path for much of my code. I'll be swapping out many exists and get calls later today. Thanks! I do still think it would be

I would assume that the proper name in this case is constantExpr, and not CE. This is not really an acronym, but rather a shortcut taken for some unclear reason. > On 12. Feb 2019, at 13:02, Björn Pettersson A via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > (Sorry if this subject already has been discussed, but I could not find any clear rules/recommendations.) > >

While poking around the C++ code in the dplyr package I ran across the idiom Rf_defineVar(symbol, R_UnboundValue, environment) to [sort of] remove 'symbol' from 'environment' Using it makes the R-level functions objects(), exists(), and get() somewhat inconsistent and I was wondering if that was intended. E.g., use SHLIB to make something from the following C code that

Dear group I use "restart" in part of my code, in a way that's not easily changed to "try". As I convert code from R1.5.0 to R1.6.1, I'm getting ugly messages; the help system says to contact r-devel, so here I am. This one's a bit complicated-- sorry! The context is inside a debugger (I have an R and S debugger that offers stand-alone code windows, line numbered