I think you're starting in the wrong end; a better approach would be to ask *which functions even need manual lifting*?
If you have unary and binary plus, base has fallbacks that handle multiple-argument plus for you (so that e.g. `+(a, b, c) = +(+(a, b), c)` if the types of `a`, `b` and `c` in that combo don't have a three-argument method). The same thing goes for subtraction, multiplication and a host of other operators. Thus, there is no need to implement lifting for *all* methods in base - better, implement just the ones you need, and let base figure out how to use the methods you define. I usually find that the best approach is to start working with just one or two method additions, and then start coding. Whenever I run on a no-method-error, I know of another method I need to define. If I don't get any no-method-errors, I'm done :) // T On Tuesday, October 6, 2015 at 9:37:01 PM UTC+2, Data Pulverizer wrote: > > p.s. I am aware that unary function template would only add one to your > collection overall with meta programming but more than two and three > parameter and code starts to get large or maybe I'm just lazy. > > On Tuesday, October 6, 2015 at 8:30:00 PM UTC+1, [email protected] > wrote: >> >> Hi Thomas, >> >> At first I started by taking this kind of approach but what if you want >> to lift all the relevant functions in Julia Base? Some are unary, binary, >> and then other have multiple parameters and you also have to think about >> all the combinations of parameters that you could have. The current >> approach I am taking would allow you to lift all the relevant functions in >> Julia Base without having to write all the combinations of functions. And >> as you rightly pointed out in a previous email, Julia language can change, >> its constantly being developed. Therefore I am trying to use a small code >> set that does what we it needs to do but has a minimal maintenance >> requirement. In the end I would like to do: >> >> Importall Base >> fun_names = names(Base) #[or a relevant selection of this] >> >> # Small lift code goes here ... >> ... >> # Then we are done >> >> >> >> On Tuesday, October 6, 2015 at 8:32:38 AM UTC+1, Tomas Lycken wrote: >>> >>> Sorry, do this instead to make sure that the code is type stable: >>> >>> +{S,T}(x::Nullable{S}, y::Nullable{T}) = isnull(x) || isnull(y) ? >>> Nullable{promote_type(S,T)}() : Nullable(x.value + y.value) >>> +{S,T}(x::Nullable{S}, y::T) = +(x, Nullable(y)) >>> +{S,T}(x::T, y::Nullable{S}) = +(y, x) >>> >>> // T >>> >>> On Tuesday, October 6, 2015 at 9:31:15 AM UTC+2, Tomas Lycken wrote: >>> >>> It seems that you should be able to do this by defining new methods for >>>> the operations you need to support. For addition, you could do >>>> >>>> ``` >>>> +{S,T}(x::Nullable{S}, y::Nullable{T}) = isnull(x) || isnull(y) ? >>>> Nullable{promote_type(S,T)}() : x.value + y.value >>>> +{S,T}(x::Nullable{S}, y::T) = +(x, Nullable(y)) >>>> +{S,T}(x::T, y::Nullable{S}) = +(y, x) >>>> ``` >>>> >>>> For other operations, you would do similar things. >>>> >>>> // T >>>> >>>> >>>> On Tuesday, October 6, 2015 at 4:33:05 AM UTC+2, [email protected] >>>> wrote: >>>>> >>>>> I'd like to be able to do for example: >>>>> >>>>> Nullable(3.) + 6 = Nullable(9.) >>>>> >>>>> as well as >>>>> >>>>> Nullable(3.) + Nullable(6) = Nullable(9) >>>>> >>>>> All types interacting with Nullables -> Nullable >>>>> >>>>> >>> >>
