WIP: Staged functions

[Keno]

This is my work in progress for staged functions (#7311). It almost works, but there's a few things left to discuss.

• Syntax: @StefanKarpinski hates stagedfunction foo(); end. @JeffBezanson proposed staged foo(); end, though there's the question if we want to reserve that keyword
• Caching. E.g. consider the following:

julia> stagedfunction foo(a,b)
       println(a,b)
       :(a+b)
       end

julia> foo(1,2)
Int64Int64
3

julia> foo(1,2)
3

julia> bar() = foo(1,2)
bar (generic function with 1 method)

julia> bar()
Int64Int64
Int64Int64
3

julia> bar()
3

julia> baz() = foo(1,2)
baz (generic function with 1 method)

julia> baz()
Int64Int64
Int64Int64
3

Hopefully calling the staged function that many times can be avoided. In any case, this point isn't critical.

• Staged functions throwing errors. I'm not handling this yet. In the runtime case this mostly works already, but for type inference we need to intercept and return Any/NF.
• Documentation

Thanks to @timholy and @jakebolewski for hacking on this with me on Saturday.

[JeffBezanson]

I don't think we should use staged. Not worth taking a dictionary word for this.

[JeffBezanson]

I don't think we should use staged. Not worth taking a dictionary word for this.

[timholy]

Hmm, that is odd behavior. It seems to suggest that the specifically-compiled variants are not getting inserted into the methods table properly. What does methods(foo) say after you call foo(1,2)? What does it say at the end after defining bar and baz?

[timholy]

Hmm, that is odd behavior. It seems to suggest that the specifically-compiled variants are not getting inserted into the methods table properly. What does methods(foo) say after you call foo(1,2)? What does it say at the end after defining bar and baz?

[timholy]

Also, am I right in guessing that more needs to be done to handle splatted arguments?

[timholy]

Also, am I right in guessing that more needs to be done to handle splatted arguments?

[JeffBezanson]

A rule of thumb is that the system should behave as if the code generator did not exist, and all of its possible outputs have been written manually in a magic infinite source file.

[JeffBezanson]

A rule of thumb is that the system should behave as if the code generator did not exist, and all of its possible outputs have been written manually in a magic infinite source file.

[Keno]

I'm not sure about splatted arguments. Haven't tried. About the method cache, I think it is being entered correctly (see the second call to foo). The problem is probably inlining.

@JeffBezanson That analogy doesn't really work though, unless you want to add the generated methods to mt->defs and even then they would only be there after being called.

[Keno]

I'm not sure about splatted arguments. Haven't tried. About the method cache, I think it is being entered correctly (see the second call to foo). The problem is probably inlining.

@JeffBezanson That analogy doesn't really work though, unless you want to add the generated methods to mt->defs and even then they would only be there after being called.

[JeffBezanson]

The rule of thumb should be followed to the extent possible. It's there to resolve design decisions that could go either way.

[JeffBezanson]

The rule of thumb should be followed to the extent possible. It's there to resolve design decisions that could go either way.

[timholy]

Looks like we're super-close, but that splatting seems to be a problem. Check this out (we are so close to having awesome array views!):

A = rand(5,5,3);
B = slice(A, 1:3, 2, 1:3);
stagedfunction mygetindex(S::SubArray, indexes::Real...)
    println(S)
    T, N, A, I = S.parameters
    if N != length(indexes)
        error("Wrong number of indexes supplied")
    end
    NP = length(I)
    indexexprs = Array(Expr, NP)
    j = 1
    for i = 1:NP
        println(i)
        println(j)
        println(I[i])
        if I[i] == Int
            indexexprs[i] = :(S.indexes[$i])
        else
            indexexprs[i] = :(S.indexes[$i][indexes[$j]])
            j += 1
        end
    end
    println(indexexprs)
    ex = :(S[$(indexexprs...)])
    println(ex)
    ex
end

julia> mygetindex(B, 2, 2)
SubArray{Float64,2,Array{Float64,3},(UnitRange{Int64},Int64,UnitRange{Int64})}
1
1
UnitRange{Int64}
2
2
Int64
3
2
UnitRange{Int64}
[:(S.indexes[1][indexes[1]]),:(S.indexes[2]),:(S.indexes[3][indexes[2]])]
S[S.indexes[1][indexes[1]],S.indexes[2],S.indexes[3][indexes[2]]]
ERROR: syntax: "Array{Any, 1}" is not a valid function argument name

Ideally the compiled function should have a signature like this:

mygetindex(S::SubArray{Float64,2,Array{Float64,3},(UnitRange{Int64},Int64,UnitRange{Int64})}, indexes_1::Int, indexes_2::Int)

but I think it's just the naming that's causing problems.

[timholy]

Looks like we're super-close, but that splatting seems to be a problem. Check this out (we are so close to having awesome array views!):

A = rand(5,5,3);
B = slice(A, 1:3, 2, 1:3);
stagedfunction mygetindex(S::SubArray, indexes::Real...)
    println(S)
    T, N, A, I = S.parameters
    if N != length(indexes)
        error("Wrong number of indexes supplied")
    end
    NP = length(I)
    indexexprs = Array(Expr, NP)
    j = 1
    for i = 1:NP
        println(i)
        println(j)
        println(I[i])
        if I[i] == Int
            indexexprs[i] = :(S.indexes[$i])
        else
            indexexprs[i] = :(S.indexes[$i][indexes[$j]])
            j += 1
        end
    end
    println(indexexprs)
    ex = :(S[$(indexexprs...)])
    println(ex)
    ex
end

julia> mygetindex(B, 2, 2)
SubArray{Float64,2,Array{Float64,3},(UnitRange{Int64},Int64,UnitRange{Int64})}
1
1
UnitRange{Int64}
2
2
Int64
3
2
UnitRange{Int64}
[:(S.indexes[1][indexes[1]]),:(S.indexes[2]),:(S.indexes[3][indexes[2]])]
S[S.indexes[1][indexes[1]],S.indexes[2],S.indexes[3][indexes[2]]]
ERROR: syntax: "Array{Any, 1}" is not a valid function argument name

Ideally the compiled function should have a signature like this:

mygetindex(S::SubArray{Float64,2,Array{Float64,3},(UnitRange{Int64},Int64,UnitRange{Int64})}, indexes_1::Int, indexes_2::Int)

but I think it's just the naming that's causing problems.

[porterjamesj]

💯

just wanted to register my excitement and say it was very cool to see the initial prototype work on Saturday :)

[porterjamesj]

💯

just wanted to register my excitement and say it was very cool to see the initial prototype work on Saturday :)

[porterjamesj]

also is this going to make it into 0.3 or will it be an 0.4-pre thing?

[porterjamesj]

also is this going to make it into 0.3 or will it be an 0.4-pre thing?

[timholy]

Definitely not 0.3 material.

[timholy]

Definitely not 0.3 material.

[lstagner]

While this can legitimately be called a staged function, I feel that the concept of staged functions is much more broad then how they are being applied here. Calling this a stage function would be presumptuous since there could be other functions that fit the definition of what a staged function is.

Since this is a function/macro that operates on types why not have the syntax be

typefunction foo(a,b) #or tfunction foo(a,b)

or

typemacro foo(a,b) #or tmacro foo(a,b)

[lstagner]

While this can legitimately be called a staged function, I feel that the concept of staged functions is much more broad then how they are being applied here. Calling this a stage function would be presumptuous since there could be other functions that fit the definition of what a staged function is.

Since this is a function/macro that operates on types why not have the syntax be

typefunction foo(a,b) #or tfunction foo(a,b)

or

typemacro foo(a,b) #or tmacro foo(a,b)

[IainNZ]

typemacro does have some good things going to for it too on top of that, in that its not likely to be wanted in user code, reduces possible confusion with plain old functions, and is short

[IainNZ]

typemacro does have some good things going to for it too on top of that, in that its not likely to be wanted in user code, reduces possible confusion with plain old functions, and is short

[quinnj]

typemacro has a nice ring to it. What about call site syntax? Do we want to visually distinguish, like macros, that "something funny is going on here"? I think Jeff mentioned @@foo(a,b) syntax is available for something.

[quinnj]

typemacro has a nice ring to it. What about call site syntax? Do we want to visually distinguish, like macros, that "something funny is going on here"? I think Jeff mentioned @@foo(a,b) syntax is available for something.

[JeffBezanson]

I fail to see how it's presumptuous to apply a term to something that fits its definition. What would it mean for another design or implementation to be "more staged" than this?

This can't have different syntax; the whole point is that it's part of the behavior of a generic function. Some methods might be staged, others not, transparently.

[JeffBezanson]

I fail to see how it's presumptuous to apply a term to something that fits its definition. What would it mean for another design or implementation to be "more staged" than this?

This can't have different syntax; the whole point is that it's part of the behavior of a generic function. Some methods might be staged, others not, transparently.

[JeffBezanson]

I would also be ok with a more concrete, less-jargony name possibly evoking "code generator". or "generated method", or something along those lines.

[JeffBezanson]

I would also be ok with a more concrete, less-jargony name possibly evoking "code generator". or "generated method", or something along those lines.

[quinnj]

Ah, I didn't catch that these will mesh with generic functions. Very cool.

[quinnj]

Ah, I didn't catch that these will mesh with generic functions. Very cool.

[lstagner]

@JeffBezanson The presumptuous bit is to allocate a piece of syntax for something that describes a family of functions. I would be a bit like a language defining sin(x) as trigfunction(x) . If the stagedfunction syntax could be applied to all types of staged functions it would be fine.

I think the syntax

typemacro foo(a,b)
    println(a,b)
end

foo(1,2)

would be fine since in your initial mailing list post you say

"These are a lot like macros, except they operate on types instead of
expressions. " -Jeff Bezanson

This may however cause confusion with people trying to call them like macros.(which is why I also suggested typefunction)

[lstagner]

@JeffBezanson The presumptuous bit is to allocate a piece of syntax for something that describes a family of functions. I would be a bit like a language defining sin(x) as trigfunction(x) . If the stagedfunction syntax could be applied to all types of staged functions it would be fine.

I think the syntax

typemacro foo(a,b)
    println(a,b)
end

foo(1,2)

would be fine since in your initial mailing list post you say

"These are a lot like macros, except they operate on types instead of
expressions. " -Jeff Bezanson

This may however cause confusion with people trying to call them like macros.(which is why I also suggested typefunction)

[JeffBezanson]

I hope we can find a better name. type function or t function is a term of art used elsewhere in the system to refer to functions that operate within the type domain, used by inference.

[JeffBezanson]

I hope we can find a better name. type function or t function is a term of art used elsewhere in the system to refer to functions that operate within the type domain, used by inference.

[lstagner]

Also something to consider would be something like type annotations but for functions. Like

function foo{typed}(a,b) #or foo::typed(a,b)
end

something that describes what aspects of the arguments are passed into the function e.g. in a normal function their values are passed but in a typed function their types are passed.

[lstagner]

Also something to consider would be something like type annotations but for functions. Like

function foo{typed}(a,b) #or foo::typed(a,b)
end

something that describes what aspects of the arguments are passed into the function e.g. in a normal function their values are passed but in a typed function their types are passed.

[Keno]

Both

function foo{typed}(a,b)

and

foo::typed(a,b)

already have a meaning.

[Keno]

Both

function foo{typed}(a,b)

and

foo::typed(a,b)

already have a meaning.

[lstagner]

@Keno then perhaps something like

function{Type} foo(a,b)

I kinda like this idea. Instead of Type where it passes the argument's type it could be Symbol where it just passes the argument's symbol. Default would where it passes the argument's Value

Anyway I've said my piece. I realize this is a bike shed issue so I am going to shut up about it now and let you experts take care of it.

[lstagner]

@Keno then perhaps something like

function{Type} foo(a,b)

I kinda like this idea. Instead of Type where it passes the argument's type it could be Symbol where it just passes the argument's symbol. Default would where it passes the argument's Value

Anyway I've said my piece. I realize this is a bike shed issue so I am going to shut up about it now and let you experts take care of it.

[StefanKarpinski]

typemacro or type macro (one less keyword plus more readable) strike me as good.

[StefanKarpinski]

typemacro or type macro (one less keyword plus more readable) strike me as good.

[porterjamesj]

typemacro or similar seems like it might be confusing to some in that you don't invoke these like macros; they just generate functions and lodge them in the method table for you.

[porterjamesj]

typemacro or similar seems like it might be confusing to some in that you don't invoke these like macros; they just generate functions and lodge them in the method table for you.

[mlubin]

typemacro seems confusing on the part of the user, because these functions are called like functions and not with the @ prefix. My vote is for stagedfunction.

[mlubin]

typemacro seems confusing on the part of the user, because these functions are called like functions and not with the @ prefix. My vote is for stagedfunction.

[mlubin]

jinx @porterjamesj

[mlubin]

jinx @porterjamesj

[yurivish]

What about genfunction or functiongen? These are like stagedfunction, but are a little shorter and capture the idea that what you're defining is a function generator.

[yurivish]

What about genfunction or functiongen? These are like stagedfunction, but are a little shorter and capture the idea that what you're defining is a function generator.

[porterjamesj]

@yurivish +1

[porterjamesj]

@yurivish +1

[stevengj]

@mlubin, since they generate expressions, they are seem more like macros than functions, and hence I like typemacro. Couldn't the patch be changed to call them with @?

[stevengj]

@mlubin, since they generate expressions, they are seem more like macros than functions, and hence I like typemacro. Couldn't the patch be changed to call them with @?

[Keno]

That way you couldn't have some methods of getindex that are staged.

[Keno]

That way you couldn't have some methods of getindex that are staged.

[ihnorton]

How about annotating function or the function name: function @foo() function ~foo() @function foo, etc. (I think the last one captures the duality quite well).

[ihnorton]

How about annotating function or the function name: function @foo() function ~foo() @function foo, etc. (I think the last one captures the duality quite well).

[JeffBezanson]

To me this is quite distinct from macros. I think the best approach is something that straightforwardly describes what the thing is. To that end genfunction is not bad.

[JeffBezanson]

To me this is quite distinct from macros. I think the best approach is something that straightforwardly describes what the thing is. To that end genfunction is not bad.

[mlubin]

@stevengj, from the user's perspective, whether a function is staged or not is really just an implementation detail. I don't think it deserves the @ syntax which is a warning that anything can happen.

[mlubin]

@stevengj, from the user's perspective, whether a function is staged or not is really just an implementation detail. I don't think it deserves the @ syntax which is a warning that anything can happen.

[lstagner]

These suggestions are just for fun

funcro  # FUNction maCRO
maction  #MACro funcTION
tycro  # TYpe maCRO
tytion  #TYpe funcTION
macrope  #MACRO tyPE
funpe  #FUNction tyPE

[lstagner]

These suggestions are just for fun

funcro  # FUNction maCRO
maction  #MACro funcTION
tycro  # TYpe maCRO
tytion  #TYpe funcTION
macrope  #MACRO tyPE
funpe  #FUNction tyPE

[tknopp]

I think its pretty obvious that we have to chose funcro :-)
Its such a nice word creation.

[tknopp]

I think its pretty obvious that we have to chose funcro :-)
Its such a nice word creation.

[timholy]

Regarding splatting, I see two paths forward. The first is to declare a convention:

stagedfunction myfunc(a, b...)
     blah blah
end

myfunc("Hi", 3, 7)

generates a function with the following signature:

myfunc(a::ASCIIString, b_1::Int, b_2::Int)

The "convention" part is that _i gets tacked on to the name of the ith splatted argument. Naturally, the person implementing the body of this function has to be aware of this convention in order to write the body. (FYI this is the same naming convention that Cartesian uses.)

The second option is to declare that the returned expression needs to contain the full function definition (including signature), not just the body. @Keno, @jakebolewski, and I discussed this and all think it has some potential downsides. But if you don't like the idea of magical naming conventions, this seems to be the only alternative.

Personally I vote for the naming convention approach, but I'm curious what others think.

[timholy]

Regarding splatting, I see two paths forward. The first is to declare a convention:

stagedfunction myfunc(a, b...)
     blah blah
end

myfunc("Hi", 3, 7)

generates a function with the following signature:

myfunc(a::ASCIIString, b_1::Int, b_2::Int)

The "convention" part is that _i gets tacked on to the name of the ith splatted argument. Naturally, the person implementing the body of this function has to be aware of this convention in order to write the body. (FYI this is the same naming convention that Cartesian uses.)

The second option is to declare that the returned expression needs to contain the full function definition (including signature), not just the body. @Keno, @jakebolewski, and I discussed this and all think it has some potential downsides. But if you don't like the idea of magical naming conventions, this seems to be the only alternative.

Personally I vote for the naming convention approach, but I'm curious what others think.

[timholy]

I looked into the inlining thing. code_native indeed shows these are beautifully inlined. However, I still find this a little weird:

julia> stagedfunction foo(a,b)
              println(a,b)
              :(a+b)
              end
foo (generic function with 1 method)

julia> methods(foo)
# 1 method for generic function "foo":
foo(a,b) at none:2

julia> foo(1,2)
Int64Int64
3

julia> methods(foo)
# 1 method for generic function "foo":
foo(a,b) at none:2

I would have expected to see a foo(a::Int, b::Int) method showing up upon the second call to methods. @JeffBezanson?

[timholy]

I looked into the inlining thing. code_native indeed shows these are beautifully inlined. However, I still find this a little weird:

julia> stagedfunction foo(a,b)
              println(a,b)
              :(a+b)
              end
foo (generic function with 1 method)

julia> methods(foo)
# 1 method for generic function "foo":
foo(a,b) at none:2

julia> foo(1,2)
Int64Int64
3

julia> methods(foo)
# 1 method for generic function "foo":
foo(a,b) at none:2

I would have expected to see a foo(a::Int, b::Int) method showing up upon the second call to methods. @JeffBezanson?

[Keno]

methods shows method definitions, which we aren't adding. We're adding an entry in the method cache instead. I'm not sure what to do about the varargs thing. We can't really change the signature. Maybe that needs to be resolved in codegen in general?

[Keno]

methods shows method definitions, which we aren't adding. We're adding an entry in the method cache instead. I'm not sure what to do about the varargs thing. We can't really change the signature. Maybe that needs to be resolved in codegen in general?

[mlubin]

Relating to my request in #7311:

Ideally we'd like to write staged functions where the inputs are typed expression trees, or some transformation thereof. Is this feasible?

Jeff responded:

The macro can generate a call to a staged function, passing the expression trees and, separately, all of its leaves.

How precisely would this work, given this implementation? Staged functions take only types, so we couldn't pass the expression tree as a value. Could you encode the value of the expression tree as a type?

[mlubin]

Relating to my request in #7311:

Ideally we'd like to write staged functions where the inputs are typed expression trees, or some transformation thereof. Is this feasible?

Jeff responded:

The macro can generate a call to a staged function, passing the expression trees and, separately, all of its leaves.

How precisely would this work, given this implementation? Staged functions take only types, so we couldn't pass the expression tree as a value. Could you encode the value of the expression tree as a type?

[amitmurthy]

Just generate?

[amitmurthy]

Just generate?

[timholy]

I like generated function, i.e., the past-tense. "generate" is imperative, suggesting the compiler should "do it right now," but that's not at all what's happening---each instantiation gets generated when the user needs it. In contrast, generated function implies that this is a declaration of type, and it would be grammatically incorrect to use the present tense for that.

But I'll join the chorus and just say that Jeff & Stefan should talk for 5 minutes and just make a decision.
I think it's fair to say that the rest of us are 95% likely to accept it.

[timholy]

I like generated function, i.e., the past-tense. "generate" is imperative, suggesting the compiler should "do it right now," but that's not at all what's happening---each instantiation gets generated when the user needs it. In contrast, generated function implies that this is a declaration of type, and it would be grammatically incorrect to use the present tense for that.

But I'll join the chorus and just say that Jeff & Stefan should talk for 5 minutes and just make a decision.
I think it's fair to say that the rest of us are 95% likely to accept it.

[johnmyleswhite]

I do really like generated function as well. I'm not that opposed to whitespace keywords.

Agree that Jeff, Stefan and Viral should decide.

[johnmyleswhite]

I do really like generated function as well. I'm not that opposed to whitespace keywords.

Agree that Jeff, Stefan and Viral should decide.

[amitmurthy]

Do whitespace keywords mean that generated continues to be a usable identifier on its own? That's a win.

[amitmurthy]

Do whitespace keywords mean that generated continues to be a usable identifier on its own? That's a win.

[tknopp]

It certainly means more whitespace magic in the parser, no? ;-)

[tknopp]

It certainly means more whitespace magic in the parser, no? ;-)

[toivoh]

Or generator function? I like generated function as well, but most of all I
like the functionality :)
On 21 Nov 2014 13:34, "Tobias Knopp" notifications@github.com wrote:

It certainly means more whitespace magic in the parser, no? ;-)

—
Reply to this email directly or view it on GitHub
#7474 (comment).

[toivoh]

Or generator function? I like generated function as well, but most of all I
like the functionality :)
On 21 Nov 2014 13:34, "Tobias Knopp" notifications@github.com wrote:

It certainly means more whitespace magic in the parser, no? ;-)

—
Reply to this email directly or view it on GitHub
#7474 (comment).

[toivoh]

Though generator is a pretty useful variable name otoh.

[toivoh]

Though generator is a pretty useful variable name otoh.

[timholy]

See above for concerns about generator.

The reason for the whitespace: we'll surely have generated type and generated immutable someday. Using the whitespace means that only one new keyword needs to be added to the parser, not three.

Also, I highlighted Jeff and Stefan above because I thought I remembered that Stefan seems the least happy of anyone with these recent name proposals. But then I just re-read some of the discussion, and Stefan said he'd go for generated function, so it seems there's really quite a lot of agreement on that name. However, since the parser is not my strong suit 😄 it won't be me who makes that change.

[timholy]

See above for concerns about generator.

The reason for the whitespace: we'll surely have generated type and generated immutable someday. Using the whitespace means that only one new keyword needs to be added to the parser, not three.

Also, I highlighted Jeff and Stefan above because I thought I remembered that Stefan seems the least happy of anyone with these recent name proposals. But then I just re-read some of the discussion, and Stefan said he'd go for generated function, so it seems there's really quite a lot of agreement on that name. However, since the parser is not my strong suit 😄 it won't be me who makes that change.

[johnmyleswhite]

Man, DataFrames could be so much better if we had generated type.

[johnmyleswhite]

Man, DataFrames could be so much better if we had generated type.

[StefanKarpinski]

It's bit the prettiest but how about just a @generated macro? No syntax changes required.

On Nov 21, 2014, at 9:01 AM, Tim Holy notifications@github.com wrote:

See above for concerns about generator.

The reason for the whitespace: we'll surely have generated type and generated immutable someday. Using the whitespace means that only one new keyword needs to be added to the parser, not three.

Also, I highlighted Jeff and Stefan above because I thought I remembered that Stefan seems the least happy of anyone with these recent name proposals. But then I just re-read some of the discussion, and Stefan said he'd go for generated function, so it seems there's really quite a lot of agreement on that name. However, since the parser is not my strong suit it won't be me who makes that change.

—
Reply to this email directly or view it on GitHub.

[StefanKarpinski]

It's bit the prettiest but how about just a @generated macro? No syntax changes required.

On Nov 21, 2014, at 9:01 AM, Tim Holy notifications@github.com wrote:

See above for concerns about generator.

The reason for the whitespace: we'll surely have generated type and generated immutable someday. Using the whitespace means that only one new keyword needs to be added to the parser, not three.

Also, I highlighted Jeff and Stefan above because I thought I remembered that Stefan seems the least happy of anyone with these recent name proposals. But then I just re-read some of the discussion, and Stefan said he'd go for generated function, so it seems there's really quite a lot of agreement on that name. However, since the parser is not my strong suit it won't be me who makes that change.

—
Reply to this email directly or view it on GitHub.

[MikeInnes]

If we're using white space anyway, seems reasonable to just use a macro – @generated function ... or @gen function... (edit: ok, Stefan got there first)

I also quite liked fucro, but that's probably why I'm not making the decisions around here.

[MikeInnes]

If we're using white space anyway, seems reasonable to just use a macro – @generated function ... or @gen function... (edit: ok, Stefan got there first)

I also quite liked fucro, but that's probably why I'm not making the decisions around here.

[toivoh]

Oh, forgot about python generators :) (which I indeed hope that we will have at some point)

[toivoh]

Oh, forgot about python generators :) (which I indeed hope that we will have at some point)

[StefanKarpinski]

+1 for @generated function, @generated type, etc.

[StefanKarpinski]

+1 for @generated function, @generated type, etc.

[Jutho]

Generated types can be implemented right now using the tricks used in #8432. Not perfect, but still very convenient until we have the full thing. In fact, it shouldn't be to hard to implement a general scheme for this using a macro, which could then be called @generate(d). This could provide a unified approach towards generated functions and types. However, what transformation should @generate(d) apply to :function, i.e. the child still needs a name, unless the generated/staged aspect is indicated using the :meta mechanism.

With respect to name: I would also prefer generated if it is a keyword, but most macros seem to have a name which is a verb in the present tense. Also compare to the original @ngenerate macro in Base.Cartesian. No strong preference from my side.

[Jutho]

Generated types can be implemented right now using the tricks used in #8432. Not perfect, but still very convenient until we have the full thing. In fact, it shouldn't be to hard to implement a general scheme for this using a macro, which could then be called @generate(d). This could provide a unified approach towards generated functions and types. However, what transformation should @generate(d) apply to :function, i.e. the child still needs a name, unless the generated/staged aspect is indicated using the :meta mechanism.

With respect to name: I would also prefer generated if it is a keyword, but most macros seem to have a name which is a verb in the present tense. Also compare to the original @ngenerate macro in Base.Cartesian. No strong preference from my side.

[timholy]

Although @ngenerate is imperative: generate them now, at parsing time.

[timholy]

Although @ngenerate is imperative: generate them now, at parsing time.

[StefanKarpinski]

I agree with the argument that it should be @generated. There are two flavors of macro: imperatives and annotations – this is more of an annotation than an imperative.

[StefanKarpinski]

I agree with the argument that it should be @generated. There are two flavors of macro: imperatives and annotations – this is more of an annotation than an imperative.

[JeffBezanson]

I like @generated too. It has all the virtues of generated function plus avoids adding a new keyword. Macro names certainly do not need to be verbs in the present tense. This is not past tense either; it's a participle, as in "functions are generated on demand".

[JeffBezanson]

I like @generated too. It has all the virtues of generated function plus avoids adding a new keyword. Macro names certainly do not need to be verbs in the present tense. This is not past tense either; it's a participle, as in "functions are generated on demand".

[Jutho]

On 21 Nov 2014, at 16:18, Tim Holy notifications@github.com wrote:

Although @ngenerate is imperative: generate them now, at parsing time.

—

Indeed. I agree 100%. +1 for @generated.

[Jutho]

On 21 Nov 2014, at 16:18, Tim Holy notifications@github.com wrote:

Although @ngenerate is imperative: generate them now, at parsing time.

—

Indeed. I agree 100%. +1 for @generated.

[ViralBShah]

+1 for @generated. No whitespace in keywords is nice too. Visually, the macro syntax it also alerts you that something will run at an earlier stage.

[ViralBShah]

+1 for @generated. No whitespace in keywords is nice too. Visually, the macro syntax it also alerts you that something will run at an earlier stage.

[johnmyleswhite]

If we make this look like a macro, what will macroexpand produce? I'm not sure I like the idea that this looks like a macro, but doesn't work like other macros.

[johnmyleswhite]

If we make this look like a macro, what will macroexpand produce? I'm not sure I like the idea that this looks like a macro, but doesn't work like other macros.

[amitmurthy]

I agree with John. The @ convention is that code is generated when it is used. While defining the generator plain keyword macro is used. +1 for generated function.

[amitmurthy]

I agree with John. The @ convention is that code is generated when it is used. While defining the generator plain keyword macro is used. +1 for generated function.

[tonyhffong]

How about using an empty curly?

function f{}( ... )
end

No new reserved word. No need to change editor model. The empty curly suggests that, Instead of parametrizing the function outside, we do that inside...

Edit: ok, f{}{ T<: AbstractArray }( x::T ) ... doesn't look quite right. Never mind me.

[tonyhffong]

How about using an empty curly?

function f{}( ... )
end

No new reserved word. No need to change editor model. The empty curly suggests that, Instead of parametrizing the function outside, we do that inside...

Edit: ok, f{}{ T<: AbstractArray }( x::T ) ... doesn't look quite right. Never mind me.

[MikeInnes]

@johnmyleswhite The idea isn't to pretend it's a macro, but for it to actually be a macro. @generated would be a very simple macro that inserts some metadata into the (function/type/whatever) expression for the compiler to pick up on.

We have @inline already doing this, so it's not exactly unprecedented (although admittedly @generated would change the semantics a lot more than @inline).

[MikeInnes]

@johnmyleswhite The idea isn't to pretend it's a macro, but for it to actually be a macro. @generated would be a very simple macro that inserts some metadata into the (function/type/whatever) expression for the compiler to pick up on.

We have @inline already doing this, so it's not exactly unprecedented (although admittedly @generated would change the semantics a lot more than @inline).

[timholy]

To follow up on @one-more-minute's point, see http://docs.julialang.org/en/latest/devdocs/meta/

[timholy]

To follow up on @one-more-minute's point, see http://docs.julialang.org/en/latest/devdocs/meta/

[porterjamesj]

I think the crucial point is that it's the definition of a generated function that involves a macro rather than the callsite—end users don't have to care. +1 for @generated from me.

[porterjamesj]

I think the crucial point is that it's the definition of a generated function that involves a macro rather than the callsite—end users don't have to care. +1 for @generated from me.

[stevengj]

Hornéd hat of shame for the lack of documentation on this....

[stevengj]

Hornéd hat of shame for the lack of documentation on this....

[timholy]

As I believe you noted elsewhere, it's hard to write documentation for something whose very name is likely to change.

[timholy]

As I believe you noted elsewhere, it's hard to write documentation for something whose very name is likely to change.

[lstagner]

It seems like the consensus that was reached was for calling them generated (functions|types|...) using the @generated (function|type|...) syntax.

[lstagner]

It seems like the consensus that was reached was for calling them generated (functions|types|...) using the @generated (function|type|...) syntax.

[timholy]

I agree, but until the syntax change happens it seems very strange to document it (with either name choice).

[timholy]

I agree, but until the syntax change happens it seems very strange to document it (with either name choice).

[ViralBShah]

Why not document it with the current name, and then just update the documentation with the name change? I think a lot of people want to use staged functions and learn about them (on master), but going through the issues is a bit cumbersome for many.

[ViralBShah]

Why not document it with the current name, and then just update the documentation with the name change? I think a lot of people want to use staged functions and learn about them (on master), but going through the issues is a bit cumbersome for many.

[aviks]

Why not document it with the current name, and then just update the documentation with the name change

I realise this is more work, and I am in no position to help, but I (and I'm sure many others) would really appreciate something on those lines. Maybe even a gist with some docs and examples?

[aviks]

Why not document it with the current name, and then just update the documentation with the name change

I realise this is more work, and I am in no position to help, but I (and I'm sure many others) would really appreciate something on those lines. Maybe even a gist with some docs and examples?

[timholy]

I also confess some reluctance before #8504 gets fixed---it's a nasty problem, and it's holding even me back from using stagedfunctions more pervasively.

But, let's go for it and see what happens. If nothing else it might be more incentive to at least get some discussion about my proposed fix.

[timholy]

I also confess some reluctance before #8504 gets fixed---it's a nasty problem, and it's holding even me back from using stagedfunctions more pervasively.

But, let's go for it and see what happens. If nothing else it might be more incentive to at least get some discussion about my proposed fix.

[tonyhffong]

I wonder if we should treat function-typed argument differently in a stagedfunction. When testing types, we most likely want to do method_exists or even code_typed to see if the function supports the input/output signature in the staging phase. Having just Function at this stage isn't that helpful.

That said, it should be illegal to actually call the function-value argument at the staging phase.

[tonyhffong]

I wonder if we should treat function-typed argument differently in a stagedfunction. When testing types, we most likely want to do method_exists or even code_typed to see if the function supports the input/output signature in the staging phase. Having just Function at this stage isn't that helpful.

That said, it should be illegal to actually call the function-value argument at the staging phase.

[timholy]

It's an interesting idea. Can you expand on your goal, why checking the signature during staging is better than just trying it and seeing what error you get?

But one point is that in principle your suggestion could provide a mechanism for "function-valued argument inlining" (#3440 and perhaps #1864).

[timholy]

It's an interesting idea. Can you expand on your goal, why checking the signature during staging is better than just trying it and seeing what error you get?

But one point is that in principle your suggestion could provide a mechanism for "function-valued argument inlining" (#3440 and perhaps #1864).

[tonyhffong]

I'm playing with the idea of Functors and Monads using Traits.jl and notice the ideas are not trivial. (PR# mauro3/Traits.jl#4 (comment)). I was trying to see if I can generate associated types with the package. Let's take Functor. A Functor must support a fmap function. In Haskell it imposes that fmap :: (a->b) -> f a -> f b. So we would write something like this:

using Traits

immutable FuncFullSig{TI, TO}
    f::Function
end

@traitdef Functor{X{Y}} begin
    fmap( FuncFullSig{Y,Z}, X{Y} ) -> X{Z}
end

So when we do

a = Float64[1.0,2.0] # assume we assert Array is a Functor
b = fmap( FuncFullSig{Float64,Float64}( sin ), a ) # b should be provably Array{Float64}

It would do away with many boilerplate codes, as many types are just Functors in disguise (Nullable, Associative{K}, DataArray, etc.) . But writing FuncFullSig is a bit cumbersome. It would be really nice, when we do just b = fmap( sin, c ), the following intermediate steps happen:

• ask if typeof(c) is a Functor? (already do-able now with Traits.jl)
• if so, check if the method sin( x::T ) exists? (T is the Functor parameter of typeof(c))
• (bonus) provide type inference info that b must be a Functor of the result type

Ideally, all these would be better done only once per (Function, ArgTypes...) tuple, or the performance penalty would be massive. Stagedfunction would be an interesting place to put it, but
we are in a strange place right now, when we only know the types of arguments but not the signatures of function arguments, a challenge that is a by-product of julia's multiple-dispatch feature. (Ironically, multiple-dispatch is exactly what makes Traits.jl work.)

[tonyhffong]

I'm playing with the idea of Functors and Monads using Traits.jl and notice the ideas are not trivial. (PR# mauro3/Traits.jl#4 (comment)). I was trying to see if I can generate associated types with the package. Let's take Functor. A Functor must support a fmap function. In Haskell it imposes that fmap :: (a->b) -> f a -> f b. So we would write something like this:

using Traits

immutable FuncFullSig{TI, TO}
    f::Function
end

@traitdef Functor{X{Y}} begin
    fmap( FuncFullSig{Y,Z}, X{Y} ) -> X{Z}
end

So when we do

a = Float64[1.0,2.0] # assume we assert Array is a Functor
b = fmap( FuncFullSig{Float64,Float64}( sin ), a ) # b should be provably Array{Float64}

It would do away with many boilerplate codes, as many types are just Functors in disguise (Nullable, Associative{K}, DataArray, etc.) . But writing FuncFullSig is a bit cumbersome. It would be really nice, when we do just b = fmap( sin, c ), the following intermediate steps happen:

• ask if typeof(c) is a Functor? (already do-able now with Traits.jl)
• if so, check if the method sin( x::T ) exists? (T is the Functor parameter of typeof(c))
• (bonus) provide type inference info that b must be a Functor of the result type

Ideally, all these would be better done only once per (Function, ArgTypes...) tuple, or the performance penalty would be massive. Stagedfunction would be an interesting place to put it, but
we are in a strange place right now, when we only know the types of arguments but not the signatures of function arguments, a challenge that is a by-product of julia's multiple-dispatch feature. (Ironically, multiple-dispatch is exactly what makes Traits.jl work.)