infer return type of script

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

infer return type of script

JamieEchlin
Hi...

Is it possible to infer the return type, or types of a script during static compilation? Presumably there is always a finite list of branches where the script could end.

I'm looking at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor#getInferredReturnType, but I'm not really sure how to call it from a type checking script, nor what adds the inferred return type to the metadata which is used in that method.

cheers, jamie
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: infer return type of script

shils
You could call 'getInferredReturnType' on the 'run' method node of your script class, but inferred return types only appear to be stored for closures and certain binary expressions (based on the usages of the INFERRED_RETURN_TYPE marker and the storeInferredReturnType method).

You could also add all implicit return statements to the 'run' method via ReturnAdder, and then infer a return type by visiting all of the return statements, but I'm not sure if that kind of AST modification in a type checking extension is safe. 

Shil

On Mon, Sep 21, 2015 at 4:34 PM, Jamie Echlin <[hidden email]> wrote:
Hi...

Is it possible to infer the return type, or types of a script during static compilation? Presumably there is always a finite list of branches where the script could end.

I'm looking at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor#getInferredReturnType, but I'm not really sure how to call it from a type checking script, nor what adds the inferred return type to the metadata which is used in that method.

cheers, jamie

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: infer return type of script

shils
Actually, the second option can be made safe by initializing ReturnAdder with a listener, which will allow you to 'visit' all implicit returns without actually adding return statements.

On Mon, Sep 21, 2015 at 5:30 PM, Shil Sinha <[hidden email]> wrote:
You could call 'getInferredReturnType' on the 'run' method node of your script class, but inferred return types only appear to be stored for closures and certain binary expressions (based on the usages of the INFERRED_RETURN_TYPE marker and the storeInferredReturnType method).

You could also add all implicit return statements to the 'run' method via ReturnAdder, and then infer a return type by visiting all of the return statements, but I'm not sure if that kind of AST modification in a type checking extension is safe. 

Shil

On Mon, Sep 21, 2015 at 4:34 PM, Jamie Echlin <[hidden email]> wrote:
Hi...

Is it possible to infer the return type, or types of a script during static compilation? Presumably there is always a finite list of branches where the script could end.

I'm looking at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor#getInferredReturnType, but I'm not really sure how to call it from a type checking script, nor what adds the inferred return type to the metadata which is used in that method.

cheers, jamie


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: infer return type of script

JamieEchlin
Hi Shil,

I did that actually, but it tells me the return type of the run method of Script is Object. Which is expected, if it's just looking at the actual method signature.

But what I was hoping for is that given a script:
"new Double(2)"

it would be able to infer the actual return type is a Double. Now, I can imagine scripts where you randomly pick from any class on the classpath, invoke a no-args constructor, and return that... in that case I don't expect magic. But most scripts have one or two possible return statements (maybe implicit), I'm wondering if there is already code that can statically analyse a method/script and say that there are only one, two or whatever possible return types.

I'll take a look at ReturnAdder, thanks for that.

cheers, jamie


On Mon, Sep 21, 2015 at 11:55 PM, Shil Sinha <[hidden email]> wrote:
Actually, the second option can be made safe by initializing ReturnAdder with a listener, which will allow you to 'visit' all implicit returns without actually adding return statements.

On Mon, Sep 21, 2015 at 5:30 PM, Shil Sinha <[hidden email]> wrote:
You could call 'getInferredReturnType' on the 'run' method node of your script class, but inferred return types only appear to be stored for closures and certain binary expressions (based on the usages of the INFERRED_RETURN_TYPE marker and the storeInferredReturnType method).

You could also add all implicit return statements to the 'run' method via ReturnAdder, and then infer a return type by visiting all of the return statements, but I'm not sure if that kind of AST modification in a type checking extension is safe. 

Shil

On Mon, Sep 21, 2015 at 4:34 PM, Jamie Echlin <[hidden email]> wrote:
Hi...

Is it possible to infer the return type, or types of a script during static compilation? Presumably there is always a finite list of branches where the script could end.

I'm looking at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor#getInferredReturnType, but I'm not really sure how to call it from a type checking script, nor what adds the inferred return type to the metadata which is used in that method.

cheers, jamie



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: infer return type of script

Cédric Champeau
Just for context and history, early versions of the type checker had return type inference for methods too. However, we removed it for a good reason: overrides. A method "foo" in class A can have an inferred type T, but "foo" from B extends A could very well have a different inferred type T2. So you can make no guarantee, at least for non private methods.


2015-09-22 11:19 GMT+02:00 Jamie Echlin <[hidden email]>:
Hi Shil,

I did that actually, but it tells me the return type of the run method of Script is Object. Which is expected, if it's just looking at the actual method signature.

But what I was hoping for is that given a script:
"new Double(2)"

it would be able to infer the actual return type is a Double. Now, I can imagine scripts where you randomly pick from any class on the classpath, invoke a no-args constructor, and return that... in that case I don't expect magic. But most scripts have one or two possible return statements (maybe implicit), I'm wondering if there is already code that can statically analyse a method/script and say that there are only one, two or whatever possible return types.

I'll take a look at ReturnAdder, thanks for that.

cheers, jamie


On Mon, Sep 21, 2015 at 11:55 PM, Shil Sinha <[hidden email]> wrote:
Actually, the second option can be made safe by initializing ReturnAdder with a listener, which will allow you to 'visit' all implicit returns without actually adding return statements.

On Mon, Sep 21, 2015 at 5:30 PM, Shil Sinha <[hidden email]> wrote:
You could call 'getInferredReturnType' on the 'run' method node of your script class, but inferred return types only appear to be stored for closures and certain binary expressions (based on the usages of the INFERRED_RETURN_TYPE marker and the storeInferredReturnType method).

You could also add all implicit return statements to the 'run' method via ReturnAdder, and then infer a return type by visiting all of the return statements, but I'm not sure if that kind of AST modification in a type checking extension is safe. 

Shil

On Mon, Sep 21, 2015 at 4:34 PM, Jamie Echlin <[hidden email]> wrote:
Hi...

Is it possible to infer the return type, or types of a script during static compilation? Presumably there is always a finite list of branches where the script could end.

I'm looking at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor#getInferredReturnType, but I'm not really sure how to call it from a type checking script, nor what adds the inferred return type to the metadata which is used in that method.

cheers, jamie




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: infer return type of script

JamieEchlin
No, I guess so. So it sounds like you're saying I should forget it and move on to the next thing? I.e. it's not feasible to get at this in a static analysis context?

On Tue, Sep 22, 2015 at 10:24 AM, Cédric Champeau <[hidden email]> wrote:
Just for context and history, early versions of the type checker had return type inference for methods too. However, we removed it for a good reason: overrides. A method "foo" in class A can have an inferred type T, but "foo" from B extends A could very well have a different inferred type T2. So you can make no guarantee, at least for non private methods.


2015-09-22 11:19 GMT+02:00 Jamie Echlin <[hidden email]>:
Hi Shil,

I did that actually, but it tells me the return type of the run method of Script is Object. Which is expected, if it's just looking at the actual method signature.

But what I was hoping for is that given a script:
"new Double(2)"

it would be able to infer the actual return type is a Double. Now, I can imagine scripts where you randomly pick from any class on the classpath, invoke a no-args constructor, and return that... in that case I don't expect magic. But most scripts have one or two possible return statements (maybe implicit), I'm wondering if there is already code that can statically analyse a method/script and say that there are only one, two or whatever possible return types.

I'll take a look at ReturnAdder, thanks for that.

cheers, jamie


On Mon, Sep 21, 2015 at 11:55 PM, Shil Sinha <[hidden email]> wrote:
Actually, the second option can be made safe by initializing ReturnAdder with a listener, which will allow you to 'visit' all implicit returns without actually adding return statements.

On Mon, Sep 21, 2015 at 5:30 PM, Shil Sinha <[hidden email]> wrote:
You could call 'getInferredReturnType' on the 'run' method node of your script class, but inferred return types only appear to be stored for closures and certain binary expressions (based on the usages of the INFERRED_RETURN_TYPE marker and the storeInferredReturnType method).

You could also add all implicit return statements to the 'run' method via ReturnAdder, and then infer a return type by visiting all of the return statements, but I'm not sure if that kind of AST modification in a type checking extension is safe. 

Shil

On Mon, Sep 21, 2015 at 4:34 PM, Jamie Echlin <[hidden email]> wrote:
Hi...

Is it possible to infer the return type, or types of a script during static compilation? Presumably there is always a finite list of branches where the script could end.

I'm looking at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor#getInferredReturnType, but I'm not really sure how to call it from a type checking script, nor what adds the inferred return type to the metadata which is used in that method.

cheers, jamie





Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: infer return type of script

Cédric Champeau
Not necessarily. The question is what you would use that information for.

2015-09-22 11:36 GMT+02:00 Jamie Echlin <[hidden email]>:
No, I guess so. So it sounds like you're saying I should forget it and move on to the next thing? I.e. it's not feasible to get at this in a static analysis context?

On Tue, Sep 22, 2015 at 10:24 AM, Cédric Champeau <[hidden email]> wrote:
Just for context and history, early versions of the type checker had return type inference for methods too. However, we removed it for a good reason: overrides. A method "foo" in class A can have an inferred type T, but "foo" from B extends A could very well have a different inferred type T2. So you can make no guarantee, at least for non private methods.


2015-09-22 11:19 GMT+02:00 Jamie Echlin <[hidden email]>:
Hi Shil,

I did that actually, but it tells me the return type of the run method of Script is Object. Which is expected, if it's just looking at the actual method signature.

But what I was hoping for is that given a script:
"new Double(2)"

it would be able to infer the actual return type is a Double. Now, I can imagine scripts where you randomly pick from any class on the classpath, invoke a no-args constructor, and return that... in that case I don't expect magic. But most scripts have one or two possible return statements (maybe implicit), I'm wondering if there is already code that can statically analyse a method/script and say that there are only one, two or whatever possible return types.

I'll take a look at ReturnAdder, thanks for that.

cheers, jamie


On Mon, Sep 21, 2015 at 11:55 PM, Shil Sinha <[hidden email]> wrote:
Actually, the second option can be made safe by initializing ReturnAdder with a listener, which will allow you to 'visit' all implicit returns without actually adding return statements.

On Mon, Sep 21, 2015 at 5:30 PM, Shil Sinha <[hidden email]> wrote:
You could call 'getInferredReturnType' on the 'run' method node of your script class, but inferred return types only appear to be stored for closures and certain binary expressions (based on the usages of the INFERRED_RETURN_TYPE marker and the storeInferredReturnType method).

You could also add all implicit return statements to the 'run' method via ReturnAdder, and then infer a return type by visiting all of the return statements, but I'm not sure if that kind of AST modification in a type checking extension is safe. 

Shil

On Mon, Sep 21, 2015 at 4:34 PM, Jamie Echlin <[hidden email]> wrote:
Hi...

Is it possible to infer the return type, or types of a script during static compilation? Presumably there is always a finite list of branches where the script could end.

I'm looking at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor#getInferredReturnType, but I'm not really sure how to call it from a type checking script, nor what adds the inferred return type to the metadata which is used in that method.

cheers, jamie






Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: infer return type of script

JamieEchlin
The question is what you would use that information for

So, basically, users provide a script in the UI, the value that it returned is indexed (in Lucene) by one of several various indexers that is configured elsewhere. You use JIRA, so you know what I'm talking about... it's JIRA.

Only certain return types make sense depending on the configured indexer. 

Let's say I'm using the indexer that requires a Double. It occurs to me (actually my colleague) that the script could implicitly extend some other class than Script, eg:

class DoubleScript {
    abstract Double run() 
}

This could be set on the compilerconfiguration.

I think if we do that the type-checker would point out the errors in the following script:

       if (xyz()) {

           111D

       }

       else {

           "sss"

       }



which would solve the problem. Sounds sensible?
cheers, jamie



On Tue, Sep 22, 2015 at 10:39 AM, Cédric Champeau <[hidden email]> wrote:
Not necessarily. The question is what you would use that information for.

2015-09-22 11:36 GMT+02:00 Jamie Echlin <[hidden email]>:
No, I guess so. So it sounds like you're saying I should forget it and move on to the next thing? I.e. it's not feasible to get at this in a static analysis context?

On Tue, Sep 22, 2015 at 10:24 AM, Cédric Champeau <[hidden email]> wrote:
Just for context and history, early versions of the type checker had return type inference for methods too. However, we removed it for a good reason: overrides. A method "foo" in class A can have an inferred type T, but "foo" from B extends A could very well have a different inferred type T2. So you can make no guarantee, at least for non private methods.


2015-09-22 11:19 GMT+02:00 Jamie Echlin <[hidden email]>:
Hi Shil,

I did that actually, but it tells me the return type of the run method of Script is Object. Which is expected, if it's just looking at the actual method signature.

But what I was hoping for is that given a script:
"new Double(2)"

it would be able to infer the actual return type is a Double. Now, I can imagine scripts where you randomly pick from any class on the classpath, invoke a no-args constructor, and return that... in that case I don't expect magic. But most scripts have one or two possible return statements (maybe implicit), I'm wondering if there is already code that can statically analyse a method/script and say that there are only one, two or whatever possible return types.

I'll take a look at ReturnAdder, thanks for that.

cheers, jamie


On Mon, Sep 21, 2015 at 11:55 PM, Shil Sinha <[hidden email]> wrote:
Actually, the second option can be made safe by initializing ReturnAdder with a listener, which will allow you to 'visit' all implicit returns without actually adding return statements.

On Mon, Sep 21, 2015 at 5:30 PM, Shil Sinha <[hidden email]> wrote:
You could call 'getInferredReturnType' on the 'run' method node of your script class, but inferred return types only appear to be stored for closures and certain binary expressions (based on the usages of the INFERRED_RETURN_TYPE marker and the storeInferredReturnType method).

You could also add all implicit return statements to the 'run' method via ReturnAdder, and then infer a return type by visiting all of the return statements, but I'm not sure if that kind of AST modification in a type checking extension is safe. 

Shil

On Mon, Sep 21, 2015 at 4:34 PM, Jamie Echlin <[hidden email]> wrote:
Hi...

Is it possible to infer the return type, or types of a script during static compilation? Presumably there is always a finite list of branches where the script could end.

I'm looking at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor#getInferredReturnType, but I'm not really sure how to call it from a type checking script, nor what adds the inferred return type to the metadata which is used in that method.

cheers, jamie







Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: infer return type of script

Cédric Champeau
mmm, makes sense. That's worth a try!

2015-09-22 14:04 GMT+02:00 Jamie Echlin <[hidden email]>:
The question is what you would use that information for

So, basically, users provide a script in the UI, the value that it returned is indexed (in Lucene) by one of several various indexers that is configured elsewhere. You use JIRA, so you know what I'm talking about... it's JIRA.

Only certain return types make sense depending on the configured indexer. 

Let's say I'm using the indexer that requires a Double. It occurs to me (actually my colleague) that the script could implicitly extend some other class than Script, eg:

class DoubleScript {
    abstract Double run() 
}

This could be set on the compilerconfiguration.

I think if we do that the type-checker would point out the errors in the following script:

       if (xyz()) {

           111D

       }

       else {

           "sss"

       }



which would solve the problem. Sounds sensible?
cheers, jamie



On Tue, Sep 22, 2015 at 10:39 AM, Cédric Champeau <[hidden email]> wrote:
Not necessarily. The question is what you would use that information for.

2015-09-22 11:36 GMT+02:00 Jamie Echlin <[hidden email]>:
No, I guess so. So it sounds like you're saying I should forget it and move on to the next thing? I.e. it's not feasible to get at this in a static analysis context?

On Tue, Sep 22, 2015 at 10:24 AM, Cédric Champeau <[hidden email]> wrote:
Just for context and history, early versions of the type checker had return type inference for methods too. However, we removed it for a good reason: overrides. A method "foo" in class A can have an inferred type T, but "foo" from B extends A could very well have a different inferred type T2. So you can make no guarantee, at least for non private methods.


2015-09-22 11:19 GMT+02:00 Jamie Echlin <[hidden email]>:
Hi Shil,

I did that actually, but it tells me the return type of the run method of Script is Object. Which is expected, if it's just looking at the actual method signature.

But what I was hoping for is that given a script:
"new Double(2)"

it would be able to infer the actual return type is a Double. Now, I can imagine scripts where you randomly pick from any class on the classpath, invoke a no-args constructor, and return that... in that case I don't expect magic. But most scripts have one or two possible return statements (maybe implicit), I'm wondering if there is already code that can statically analyse a method/script and say that there are only one, two or whatever possible return types.

I'll take a look at ReturnAdder, thanks for that.

cheers, jamie


On Mon, Sep 21, 2015 at 11:55 PM, Shil Sinha <[hidden email]> wrote:
Actually, the second option can be made safe by initializing ReturnAdder with a listener, which will allow you to 'visit' all implicit returns without actually adding return statements.

On Mon, Sep 21, 2015 at 5:30 PM, Shil Sinha <[hidden email]> wrote:
You could call 'getInferredReturnType' on the 'run' method node of your script class, but inferred return types only appear to be stored for closures and certain binary expressions (based on the usages of the INFERRED_RETURN_TYPE marker and the storeInferredReturnType method).

You could also add all implicit return statements to the 'run' method via ReturnAdder, and then infer a return type by visiting all of the return statements, but I'm not sure if that kind of AST modification in a type checking extension is safe. 

Shil

On Mon, Sep 21, 2015 at 4:34 PM, Jamie Echlin <[hidden email]> wrote:
Hi...

Is it possible to infer the return type, or types of a script during static compilation? Presumably there is always a finite list of branches where the script could end.

I'm looking at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor#getInferredReturnType, but I'm not really sure how to call it from a type checking script, nor what adds the inferred return type to the metadata which is used in that method.

cheers, jamie








Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: infer return type of script

JamieEchlin
it appears to work great, thanks Cedric!

On Tue, Sep 22, 2015 at 1:05 PM, Cédric Champeau <[hidden email]> wrote:
mmm, makes sense. That's worth a try!

2015-09-22 14:04 GMT+02:00 Jamie Echlin <[hidden email]>:
The question is what you would use that information for

So, basically, users provide a script in the UI, the value that it returned is indexed (in Lucene) by one of several various indexers that is configured elsewhere. You use JIRA, so you know what I'm talking about... it's JIRA.

Only certain return types make sense depending on the configured indexer. 

Let's say I'm using the indexer that requires a Double. It occurs to me (actually my colleague) that the script could implicitly extend some other class than Script, eg:

class DoubleScript {
    abstract Double run() 
}

This could be set on the compilerconfiguration.

I think if we do that the type-checker would point out the errors in the following script:

       if (xyz()) {

           111D

       }

       else {

           "sss"

       }



which would solve the problem. Sounds sensible?
cheers, jamie



On Tue, Sep 22, 2015 at 10:39 AM, Cédric Champeau <[hidden email]> wrote:
Not necessarily. The question is what you would use that information for.

2015-09-22 11:36 GMT+02:00 Jamie Echlin <[hidden email]>:
No, I guess so. So it sounds like you're saying I should forget it and move on to the next thing? I.e. it's not feasible to get at this in a static analysis context?

On Tue, Sep 22, 2015 at 10:24 AM, Cédric Champeau <[hidden email]> wrote:
Just for context and history, early versions of the type checker had return type inference for methods too. However, we removed it for a good reason: overrides. A method "foo" in class A can have an inferred type T, but "foo" from B extends A could very well have a different inferred type T2. So you can make no guarantee, at least for non private methods.


2015-09-22 11:19 GMT+02:00 Jamie Echlin <[hidden email]>:
Hi Shil,

I did that actually, but it tells me the return type of the run method of Script is Object. Which is expected, if it's just looking at the actual method signature.

But what I was hoping for is that given a script:
"new Double(2)"

it would be able to infer the actual return type is a Double. Now, I can imagine scripts where you randomly pick from any class on the classpath, invoke a no-args constructor, and return that... in that case I don't expect magic. But most scripts have one or two possible return statements (maybe implicit), I'm wondering if there is already code that can statically analyse a method/script and say that there are only one, two or whatever possible return types.

I'll take a look at ReturnAdder, thanks for that.

cheers, jamie


On Mon, Sep 21, 2015 at 11:55 PM, Shil Sinha <[hidden email]> wrote:
Actually, the second option can be made safe by initializing ReturnAdder with a listener, which will allow you to 'visit' all implicit returns without actually adding return statements.

On Mon, Sep 21, 2015 at 5:30 PM, Shil Sinha <[hidden email]> wrote:
You could call 'getInferredReturnType' on the 'run' method node of your script class, but inferred return types only appear to be stored for closures and certain binary expressions (based on the usages of the INFERRED_RETURN_TYPE marker and the storeInferredReturnType method).

You could also add all implicit return statements to the 'run' method via ReturnAdder, and then infer a return type by visiting all of the return statements, but I'm not sure if that kind of AST modification in a type checking extension is safe. 

Shil

On Mon, Sep 21, 2015 at 4:34 PM, Jamie Echlin <[hidden email]> wrote:
Hi...

Is it possible to infer the return type, or types of a script during static compilation? Presumably there is always a finite list of branches where the script could end.

I'm looking at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor#getInferredReturnType, but I'm not really sure how to call it from a type checking script, nor what adds the inferred return type to the metadata which is used in that method.

cheers, jamie









12
Loading...