As I read it, the objection is about using the "official" ("behind-the-scenes")
julia inference engine---not the idea of using AST analysis to determine
return type. So someone needs to code up a standalone ReturnType.jl package
that performs inference using an independent implementation that can afford to
drift from what's in Base.
Independent might mean: "start by forking inference.jl, but henceforth
maintain it in a way that makes your users happy even if it diverges from
Base."
--Tim
On Friday, September 18, 2015 08:53:46 AM Tomas Lycken wrote:
> OK, so if Base.return_types is frowned upon, what is the recommended
> solution to the problem of
>
> "here's a function and a list of types; give me a container that can hold
> the results of applying this function to arguments of the type in the list"
>
> ?
>
> For this specific case, I don't think it's so bad to use Base.return_types
> anyway, since what I want to get at is actually, literally, "what will type
> inference give me from this function call?". The main argument against
> using Base.return_types outside of the compiler was that if the type
> inference algorithm changes it might break your code; in my case, I want my
> code to change with the inference algorithm, and keep giving me whatever
> the algorithm gives me.
>
> However, I eventually solved the problem differently
> <https://github.com/tlycken/Interpolations.jl/commit/18ab2653bc4bf38712918dc
> 0b4dc2e43be9acee5#diff-d9844e94478d4dd20a05dff646887c5cR22>, eliminating the
> need to call Base.return_types entirely.
>
> // T
>
> On Friday, September 18, 2015 at 5:38:40 PM UTC+2, Tom Breloff wrote:
> > Hi Michael... have you had a chance to look at OnlineStats yet?
> >
> > https://github.com/joshday/OnlineStats.jl
> >
> > On Fri, Sep 18, 2015 at 11:31 AM, Michael Francis <[email protected]
> >
> > <javascript:>> wrote:
> >> Hmm - looking at that thread I struggle to agree with the outcome.
> >>
> >> Using this function was how I stumbled on the 20% speed issue with cov in
> >> stats base (due to type instability of the named arg). cov as it
> >> currently
> >> stands will return 'Any' whereas for an input set of two vectors of
> >> Float64. The code emitted for cov is not optimal due to the type
> >> instability.
> >>
> >> To have any chance of performance in streaming time series operators I
> >> need to be able to figure out what the return type of an arbitrary
> >> function
> >> is ( say +( Float64, Float64 ) -> Float64, I use this is used to define
> >> the
> >> record type for each subsequent observation.
> >>
> >> On Friday, September 18, 2015 at 10:04:46 AM UTC-4, Tim Holy wrote:
> >>> It's considered a no-no to call Base.return_types from code:
> >>> https://github.com/JuliaLang/julia/pull/12292#issuecomment-124322950
> >>>
> >>> However, my PR expunging it (
> >>> https://github.com/JuliaLang/julia/pull/12409)
> >>> has not gotten any interest from those who objected, so I'm certain how
> >>> serious they are ;-).
> >>>
> >>> --Tim
> >>>
> >>> On Friday, September 18, 2015 05:58:03 AM Michael Francis wrote:
> >>> > I should probably submit a PR to add - the extra info
> >>> >
> >>> > On Friday, September 18, 2015 at 8:50:35 AM UTC-4, Tomas Lycken wrote:
> >>> > > In this specific use case I don't need to handle anonymous
> >>>
> >>> functions, so
> >>>
> >>> > > `Base.return_types` will probably do just fine.
> >>> > >
> >>> > > It's not documented, though, so searching in the docs didn't turn
> >>>
> >>> anything
> >>>
> >>> > > up (and even though I guess it must have been used on this list, my
> >>>
> >>> search
> >>>
> >>> > > terms apparently weren't good enough to find it.
> >>> > >
> >>> > > Thanks!
> >>> > >
> >>> > > // T
> >>> > >
> >>> > > On Friday, September 18, 2015 at 2:42:47 PM UTC+2, Michael Francis
> >>>
> >>> wrote:
> >>> > >> Yes in the sense it hands anon functions
> >>> > >>
> >>> > >> On Friday, September 18, 2015 at 8:41:16 AM UTC-4, Mauro wrote:
> >>> > >>> Is that better than Base.return_types ?
> >>> > >>>
> >>> > >>> On Fri, 2015-09-18 at 14:36, Michael Francis <[email protected]>
> >>> > >>>
> >>> > >>> wrote:
> >>> > >>> > function returns(f, types)
> >>> > >>> >
> >>> > >>> > rt = []
> >>> > >>> > if( !isdefined(f, :code) )
> >>> > >>> >
> >>> > >>> > for x in Base._methods(f,types,-1)
> >>> > >>> >
> >>> > >>> > linfo = x[3].func.code
> >>> > >>> > (tree, ty) = typeinf(linfo, x[1], x[2])
> >>> > >>> > push!(rt, ty)
> >>> > >>> >
> >>> > >>> > end
> >>> > >>> >
> >>> > >>> > else
> >>> > >>> >
> >>> > >>> > # It is a lambda, not a function, we also need the types of
> >>>
> >>> the
> >>>
> >>> > >>> bound
> >>> > >>>
> >>> > >>> > # variables to evaluate the lambda corectly
> >>> > >>> > println( types )
> >>> > >>> > linfo = f.code
> >>> > >>> > env = f.env
> >>> > >>> > (tree, ty) = typeinf(linfo, types, () )
> >>> > >>> > push!(rt, ty)
> >>> > >>> >
> >>> > >>> > end
> >>> > >>> > # If there is a set of return types we default to any for now
> >>> > >>> > # this could be converted to a union type
> >>> > >>> > if( length( rt ) == 0 )
> >>> > >>> >
> >>> > >>> > println( "Failed to resolve return type for $f, $types")
> >>> > >>> >
> >>> > >>> > elseif( length(rt) > 1 )
> >>> > >>> >
> >>> > >>> > return Any
> >>> > >>> >
> >>> > >>> > else
> >>> > >>> >
> >>> > >>> > return rt[1]
> >>> > >>> >
> >>> > >>> > end
> >>> > >>> >
> >>> > >>> > end
> >>> > >>> >
> >>> > >>> >
> >>> > >>> >
> >>> > >>> > The above is what I do - which also copes with anon-functions
> >>> > >>> >
> >>> > >>> > On Friday, September 18, 2015 at 8:32:45 AM UTC-4, Tomas Lycken
> >>>
> >>> wrote:
> >>> > >>> >> Given a function `foo(x,y)` and two *types* `TX` and `TY`, is
> >>>
> >>> there a
> >>>
> >>> > >>> way
> >>> > >>>
> >>> > >>> >> I can get the inferred return type from calling `foo(x::TX,
> >>>
> >>> y::TY)`?
> >>>
> >>> > >>> I want
> >>> > >>>
> >>> > >>> >> to do this in the compile part of a generated function, so I
> >>>
> >>> don't
> >>>
> >>> > >>> have
> >>> > >>>
> >>> > >>> >> access to any values to actually call the function with.
> >>> > >>> >>
> >>> > >>> >> I have already verified that the function `foo` is type stable,
> >>>
> >>> so
> >>>
> >>> > >>> the
> >>> > >>>
> >>> > >>> >> inferred type should be good enough for my purposes.
> >>> > >>> >>
> >>> > >>> >> Thanks,
> >>> > >>> >>
> >>> > >>> >> // T
