On Mar 20, 2011, at 06:46 , Russ Abbott wrote: > I'm afraid I disagree. As a number of people have shown, it's certainly > possible to get the end result > >> pH <- c(4.5,7,7.3,8.2,6.3) >> names(pH) <- c('area1','area2','mud','dam','middle') >> pH > area1 area2 mud dam middle > 4.5 7.0 7.3 8.2 6.3 > > using a single expression. But what makes this non-functional is that the > names() function operates on a reference to the pH object/entity/element. In > other words, the names() function has a side effect, which is not permitted > in strictly functional programming. >
Actually, it _is_ functional, sort of. The convention is that names(foo)<-bar is syntactic sugar for foo <- "names<-"(foo, bar) and if you implements assignment functions in pure R, that is exactly what you need to do. If this was followed to the letter, it would indeed be functional, but to avoid duplication of objects (in almost all cases, the returned values is assigned immediately back to the argument in the first argument), some of the frequently used examples allow destructive modification of their arguments. Hence the "sort of" above. However, this is an implementation hack, and there are cases where the destructive modification is undesirable, e.g. it is unsafe to apply the "f<-" functions directly, where it might otherwise be quite sensible do things like yesnoFactors <- lapply(dd[3:10], "levels<-" , c("yes","no")) (The hack is not something that anyone is particularly proud of, but the inefficiency of x[1] <- 1 copying unconditionally for very long vectors is a bit forbidding). > I don't know if R has threads. But imagine it did and that one ran > >> names(pH) <- c('area1','area2','mud','dam','middle') > > and > >> names(pH) <- c('areaA','areaB','dirt','blockage','center') > > in simultaneous threads. Since they are both operating on the same pH > element, it is uncertain what the result would be. That's one of the things > that functional programming prevents. No, that's not it. If there are two references to pH, names(pH) will duplicate the object before renaming and the pH name will be bound to a different object afterwards. Of course, assignment in itself allows race conditions: if one thread does x <- 1 and the other x <- 2, in the same environment. (R doesn't have multithreading, but it does allow quite complex evaluation scenarios via GUI callbacks and lazy evaluation, so the multiple reference issues have been given quite a bit of though.) > > *-- Russ * > > > > On Sat, Mar 19, 2011 at 10:22 PM, <bill.venab...@csiro.au> wrote: > >> PS the form >> >> names(p) <- c(...) >> >> is still functional, of course. It is just a bit of syntactic sugar for >> the clumsier >> >> p <- `names<-`(p, c(...)) >> >> e.g. >>> pH <- `names<-`(pH, letters[1:5]) >>> pH >> a b c d e >> 4.5 7.0 7.3 8.2 6.3 >>> >> >> >> >> -----Original Message----- >> From: Venables, Bill (CMIS, Dutton Park) >> Sent: Sunday, 20 March 2011 3:09 PM >> To: 'Gabor Grothendieck'; 'russ.abb...@gmail.com' >> Cc: 'r-help@r-project.org' >> Subject: RE: [R] R as a non-functional language >> >> The idiom I prefer is >> >> pH <- structure(c(4.5,7,7.3,8.2,6.3), >> names = c('area1','area2','mud','dam','middle')) >> >> -----Original Message----- >> From: r-help-boun...@r-project.org [mailto:r-help-boun...@r-project.org] >> On Behalf Of Gabor Grothendieck >> Sent: Sunday, 20 March 2011 2:33 PM >> To: russ.abb...@gmail.com >> Cc: r-help@r-project.org >> Subject: Re: [R] R as a non-functional language >> >> On Sun, Mar 20, 2011 at 12:20 AM, Russ Abbott <russ.abb...@gmail.com> >> wrote: >>> I'm reading Torgo (2010) *Data Mining with >>> R*<http://www.liaad.up.pt/~ltorgo/DataMiningWithR/code.html>in >>> preparation for a class I'll be teaching next quarter. Here's an >>> example >>> that is very non-functional. >>> >>>> pH <- c(4.5,7,7.3,8.2,6.3) >>>> names(pH) <- c('area1','area2','mud','dam','middle') >>>> pH >>> area1 area2 mud dam middle >>> 4.5 7.0 7.3 8.2 6.3 >>> >>> >>> This sort of thing seems to be quite common in R. >> >> Try this: >> >> pH <- setNames(c(4.5,7,7.3,8.2,6.3), >> c('area1','area2','mud','dam','middle')) >> >> >> >> >> -- >> Statistics & Software Consulting >> GKX Group, GKX Associates Inc. >> tel: 1-877-GKX-GROUP >> email: ggrothendieck at gmail.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. >> > > [[alternative HTML version deleted]] > > ______________________________________________ > 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. -- Peter Dalgaard Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd....@cbs.dk Priv: pda...@gmail.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.