All of this is syntactic sugar. Just because a language does not have
the sintax that you are used (e.g, Perl) does not make it bad/hard to
use. What is the problem if I have to type a couple of extra lines:
f <- function(x) list(a = seq_along(x), b=x*3)
result <- f(1)
r1 <- result$a
r2 <- result$b
If you don't want to pay the "keystrokes", then use some macros
(EMACS, hotKeys, etc.) to encapsulate that in a single keystroke.
As I say in my tag line: "what is the problem you are trying to solve".
On Sat, Mar 31, 2012 at 1:56 AM, Jeff Newmiller
<jdnew...@dcn.davis.ca.us> wrote:
> I agree that global side effects are a bad idea, but ivo started this by
> pointing out that it is straightforward to do this in Perl. It might be worth
> considering adding this capability to R.
> ---------------------------------------------------------------------------
> Jeff Newmiller The ..... ..... Go Live...
> DCN:<jdnew...@dcn.davis.ca.us> Basics: ##.#. ##.#. Live Go...
> Live: OO#.. Dead: OO#.. Playing
> Research Engineer (Solar/Batteries O.O#. #.O#. with
> /Software/Embedded Controllers) .OO#. .OO#. rocks...1k
> ---------------------------------------------------------------------------
> Sent from my phone. Please excuse my brevity.
>
> Bert Gunter <gunter.ber...@gene.com> wrote:
>
>>,,,But assigning to the global environment is a bad idea. You're just
>>asking for trouble -- overwriting without warning something that's
>>already there.
>>
>>May I suggest a rule of thumb: When things are difficult or clumsy to
>>do in R, don't do them.
>>
>>Of course this is not inviolable, but the OP's request may be one
>>instance where it applies.
>>
>>-- Bert
>>
>>On Fri, Mar 30, 2012 at 7:24 PM, Joshua Wiley <jwiley.ps...@gmail.com>
>>wrote:
>>> An idiom like this would also work.
>>>
>>> f <- function(a,b) list( data.frame(a+rnorm(20), b), loess( a ~ b) )
>>> lapply(seq_along(out <- f(1:20, 1:20)), function(i) assign(c("c",
>>> "d")[i], out[[i]], envir = .GlobalEnv))
>>>
>>> It is not elegant if you are doing this regularly, but, I think,
>>> functions typically return lists of output rather than assigning to
>>> the global environment because presumably one function returns
>>related
>>> objects so it makes sense for them to stay grouped in a list. If the
>>> two steps really are unrelated, then use two functions.
>>>
>>> It seems like what you want is to have a function return each object
>>> not in a list but to the global environment, but you would like to be
>>> able to give them your own names (which makes sense). If this is
>>with
>>> your own functions, you could adapt them easily to accept names and
>>> then assign to global.
>>>
>>> f <- function(a,b, names = c("a", "b")) {
>>> assign(names[1], data.frame(a + rnorm(20), b), envir = .GlobalEnv)
>>> assign(names[2], loess(a ~ b), envir = .GlobalEnv)
>>> }
>>> f(1:20, 1:20, c("c", "d"))
>>>
>>> I'm not arguing against Gabor's list function, just tossing out a few
>>> other ideas. I am not familiar with perl, but in R I am used to the
>>> thing on the left being what is assigned to; the list[a, b] assigning
>>> to global is counterintuitive to me personally.
>>>
>>> Given that this works:
>>>
>>> .GlobalEnv[["a"]] <- 1
>>> a
>>>
>>> I was hoping that:
>>>
>>> .GlobalEnv[c("c", "d")] <- f(1:20, 1:20)
>>>
>>> would also, but alas environments are not subsettable. Interesting
>>question.
>>>
>>> Cheers,
>>>
>>> Josh
>>>
>>> On Fri, Mar 30, 2012 at 6:26 PM, ivo welch <ivo.we...@gmail.com>
>>wrote:
>>>> thanks, everyone. I should have been clearer (as always). I used
>>the
>>>> numbers as an example only. I am aware that I can put numbers into
>>>> vectors and get nice R syntax. my problem is that I usually want to
>>>> return multiple and/or mixed objects, such as multiple data frames.
>> I
>>>> should have given as an example something like
>>>>
>>>> f <- function(a,b) list( data.frame(a+rnorm(20), b), loess( a ~ b)
>>)
>>>>
>>>> weidong---yes, nice syntax, but I don't want to invoke f() twice.
>>>>
>>>> peter---I don't think your unlist syntax works. I tried it.
>>>>
>>>> gabor---#1-#3 work, but aren't what I really want. #4 is exactly
>>what
>>>> I wanted. can list[] be added into the standard core R as a
>>feature?
>>>> it would seem like a natural part of the syntax for functions
>>>> returning multiple values.
>>>>
>>>> justin---mea culpa.
>>>>
>>>> regards,
>>>>
>>>> /iaw
>>>> ----
>>>> Ivo Welch (ivo.we...@gmail.com)
>>>>
>>>>
>>>>
>>>> On Fri, Mar 30, 2012 at 5:08 PM, Justin Haynes <jto...@gmail.com>
>>wrote:
>>>>> You can also take a look at
>>>>>
>>>>>
>>http://stackoverflow.com/questions/7519790/assign-multiple-new-variables-in-a-single-line-in-r
>>>>>
>>>>> which has some additional solutions.
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Mar 30, 2012 at 4:49 PM, Peter Ehlers <ehl...@ucalgary.ca>
>>wrote:
>>>>>> On 2012-03-30 15:40, ivo welch wrote:
>>>>>>>
>>>>>>> Dear R wizards: is there a clean way to assign to elements in a
>>list?
>>>>>>> what I would like to do, in pseudo R+perl notation is
>>>>>>>
>>>>>>> f<- function(a,b) list(a+b,a-b)
>>>>>>> (c,d)<- f(1,2)
>>>>>>>
>>>>>>> and have c be assigned 1+2 and d be assigned 1-2. right now, I
>>use the
>>>>>>> clunky
>>>>>>>
>>>>>>> x<- f(1,2
>>>>>>> c<- x[[1]]
>>>>>>> d<- x[[2]]
>>>>>>> rm(x)
>>>>>>>
>>>>>>> which seems awful. is there a nicer syntax?
>>>>>>>
>>>>>>> regards, /iaw
>>>>>>> ----
>>>>>>> Ivo Welch (ivo.we...@brown.edu, ivo.we...@gmail.com)
>>>>>>>
>>>>>>
>>>>>> I must be missing something. Why not just assign to a
>>>>>> vector instead of a list?
>>>>>>
>>>>>> f<- function(a,b) c(a+b,a-b)
>>>>>>
>>>>>> If it's imperative that f return a list, then you
>>>>>> could use
>>>>>>
>>>>>> (c, d) <- unlist(f(a, b))
>>>>>>
>>>>>> to get vector (c, d).
>>>>>>
>>>>>> Peter Ehlers
>>>>>>
>>>>>>
>>>>>> ______________________________________________
>>>>>> R-help@r-project.org mailing list
>>>>>> https://stat.ethz.ch/mailman/listinfo/r-help
>>>>>> PLEASE do read the posting guide
>>http://www.R-project.org/posting-guide.html
>>>>>> and provide commented, minimal, self-contained, reproducible code.
>>>>
>>>> ______________________________________________
>>>> R-help@r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-help
>>>> PLEASE do read the posting guide
>>http://www.R-project.org/posting-guide.html
>>>> and provide commented, minimal, self-contained, reproducible code.
>>>
>>>
>>>
>>> --
>>> Joshua Wiley
>>> Ph.D. Student, Health Psychology
>>> Programmer Analyst II, Statistical Consulting Group
>>> University of California, Los Angeles
>>> https://joshuawiley.com/
>>>
>>> ______________________________________________
>>> R-help@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-help
>>> PLEASE do read the posting guide
>>http://www.R-project.org/posting-guide.html
>>> and provide commented, minimal, self-contained, reproducible code.
>>
>>
>>
>>--
>>
>>Bert Gunter
>>Genentech Nonclinical Biostatistics
>>
>>Internal Contact Info:
>>Phone: 467-7374
>>Website:
>>http://pharmadevelopment.roche.com/index/pdb/pdb-functional-groups/pdb-biostatistics/pdb-ncb-home.htm
>>
>>______________________________________________
>>R-help@r-project.org mailing list
>>https://stat.ethz.ch/mailman/listinfo/r-help
>>PLEASE do read the posting guide
>>http://www.R-project.org/posting-guide.html
>>and provide commented, minimal, self-contained, reproducible code.
>
> ______________________________________________
> R-help@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
--
Jim Holtman
Data Munger Guru
What is the problem that you are trying to solve?
Tell me what you want to do, not how you want to do it.
______________________________________________
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
