I just realized that even in the non-nested case, calling from top level
"broke" some of my code "inexplicably", since the globally stored
function call gets overridden if you call Curry again. So old Curried
functions break.
Glad to have this fix.
On 5/25/2012 5:23 PM, Hadley Wickham wrote:
On Sat, May 26, 2012 at 12:30 PM, Yike Lu wrote:
> On 5/25/12 5:23 PM, Hadley Wickham wrote:
>>
>> On Fri, May 25, 2012 at 3:14 PM, Yike Lu wrote:
>>>
>>> So here's the way I'm reading this:
>>>
>>> Original:
>>> curry_call is the function body you're constructing, which is itself just
>>> a
>>>
On 5/25/12 5:23 PM, Hadley Wickham wrote:
On Fri, May 25, 2012 at 3:14 PM, Yike Lu wrote:
So here's the way I'm reading this:
Original:
curry_call is the function body you're constructing, which is itself just a
one liner which calls the symbol FUN with the appropriate substitutions.
Yup. W
On Fri, May 25, 2012 at 3:14 PM, Yike Lu wrote:
> So here's the way I'm reading this:
>
> Original:
> curry_call is the function body you're constructing, which is itself just a
> one liner which calls the symbol FUN with the appropriate substitutions.
Yup. With a bit more infrastructure you cou
So here's the way I'm reading this:
Original:
curry_call is the function body you're constructing, which is itself
just a one liner which calls the symbol FUN with the appropriate
substitutions.
call("function", [...]) calls the "function" function, which itself
takes 2 arguments: the list o
> I've been playing around with this for a while. One flaw I found - it
> doesn't handle nested Curries very well (the naive implementation in
> roxygen/functional does).
That's easily fixed:
Curry <- function(FUN, ...) {
args <- match.call(expand.dots = FALSE)$...
args$... <- as.name("...")
Hadley Wickham-2 wrote
>
> Curry <- function(FUN, ...) {
> args <- match.call(expand.dots = FALSE)$...
> args$... <- as.name("...")
>
> env <- parent.frame()
>
> if (is.name(FUN)) {
> fname <- FUN
> } else if (is.character(FUN)) {
> fname <- as.
Sharpie wrote:
> Currently, the only Curry implementation I know of is in the roxygen
> package which is kind of a weird dependency to install just for this
> one function.
I end up using Curry so much outside of Roxygen that I spun it off
into the `functional' package:
https://r-forge.r-projec
On Thu, May 5, 2011 at 9:32 AM, Hadley Wickham wrote:
> On Thu, May 5, 2011 at 8:25 AM, Hadley Wickham wrote:
>>> And it seems to work ok in terms of preserving evaluation (I can't how
>>> it could be any different to making the anonymous function yourself,
>>> unless I've missed something subtle
On Thu, May 5, 2011 at 8:25 AM, Hadley Wickham wrote:
>> And it seems to work ok in terms of preserving evaluation (I can't how
>> it could be any different to making the anonymous function yourself,
>> unless I've missed something subtle with environments and scoping)
>
> Which indeed I have. Hm
> And it seems to work ok in terms of preserving evaluation (I can't how
> it could be any different to making the anonymous function yourself,
> unless I've missed something subtle with environments and scoping)
Which indeed I have. Hmmm, need to think about this more.
Hadley
--
Assistant Pr
> Thanks, Hadley. This (i.e., different ways to prepare curry) is quite
> instructive to me.
The following update makes the generated function look a little nicer
if you pass in the name of a function:
Curry <- function(FUN, ...) {
args <- match.call(expand.dots = FALSE)$...
arg
.
>
> Duncan Murdoch
>
>> Best,
>> Ravi.
>>
>> ---
>> Ravi Varadhan, Ph.D.
>> Assistant Professor,
>> Division of Geriatric Medicine and Gerontology School of Medicine Johns
>> Hopkins Unive
: proposed new functional programming, er, function.
>> # Use of Curry
>> adaptIntegrate(Curry(f, a=0.2), lower=0, upper=2)
>
> Two objections:
>
> 1. I don't see how that is preferable to
>
> adaptIntegrate(function(x) f(x, a=0.2), lower=0, upper=2)
It's less
On Wed, May 4, 2011 at 1:11 PM, Sharpie wrote:
> Currently, the only Curry implementation I know of is in the roxygen package
> which is kind of a weird dependency to install just for this one function.
>
Not entirely comparable but the proto package supports currying of
proto arguments. For exam
Byron Ellis-2 wrote:
>
> Hi all (especially R-core) I suppose,
>
> With the introduction of the new functional programming functions into
> base I thought I'd ask for a Curry() function. I use a simple one that
> looks this:
>
> Curry = function(FUN,...) { .orig = list(...);function(...)
> do.c
> Or maybe
>
> Curry <- function(FUN, ...) {
> args <- match.call(expand.dots = FALSE)$...
> args$... <- as.name("...")
>
> curry_call <- as.call(c(list(as.name("FUN")), args))
> eval(bquote(function(...) .(curry_call)))
> }
Or one more approach:
Curry <- function(FU
>> # Use of Curry
>> adaptIntegrate(Curry(f, a=0.2), lower=0, upper=2)
>
> Two objections:
>
> 1. I don't see how that is preferable to
>
> adaptIntegrate(function(x) f(x, a=0.2), lower=0, upper=2)
It's less typing?
A more helpful use is when you have a list of functions:
funs <- list(
>> # Use of Curry
>> adaptIntegrate(Curry(f, a=0.2), lower=0, upper=2)
>
> The _concept_ of currying is useful, and maybe more can be done to
> provide guidance and education on how to do it, but adding a function
> that sometimes works and somesimes does surprising things is not the
> way to go.
10) 502-2619
email: rvarad...@jhmi.edu
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On
Behalf Of Hadley Wickham
Sent: Wednesday, May 04, 2011 10:29 AM
To: Byron Ellis
Cc: R Development Mailing List
Subject: Re: [Rd] Curry: proposed new functional
On Wed, May 4, 2011 at 10:40 AM, Ravi Varadhan wrote:
> I too would like this (being an Indian!).
>
> Here is an example that came up just yesterday with regards to solving a
> quadrature problem using the "cubature" package. The adaptIntegrate function
> does not allow additional arguments via
oject.org [mailto:r-devel-boun...@r-project.org] On
Behalf Of Hadley Wickham
Sent: Wednesday, May 04, 2011 10:29 AM
To: Byron Ellis
Cc: R Development Mailing List
Subject: Re: [Rd] Curry: proposed new functional programming, er, function.
I thought I might bring this up again - it now seems li
day, May 04, 2011 10:29 AM
To: Byron Ellis
Cc: R Development Mailing List
Subject: Re: [Rd] Curry: proposed new functional programming, er, function.
I thought I might bring this up again - it now seems like Curry would
be a natural fit with Reduce, Filter, Find, Map, Negate and Position.
Any cha
I thought I might bring this up again - it now seems like Curry would
be a natural fit with Reduce, Filter, Find, Map, Negate and Position.
Any chance we might see this in a future version of R?
Hadley
On Thu, Nov 1, 2007 at 2:00 PM, Byron Ellis wrote:
> Hi all (especially R-core) I suppose,
>
>
Hi all (especially R-core) I suppose,
With the introduction of the new functional programming functions into
base I thought I'd ask for a Curry() function. I use a simple one that
looks this:
Curry = function(FUN,...) { .orig = list(...);function(...)
do.call(FUN,c(.orig,list(...))) }
This comes
25 matches
Mail list logo
