> output of methods()....

If I wasn't typing on my phone, I would have been clearer. Methods() has a
two argument form which will specializ


On Monday, June 2, 2014, David Moon <[email protected]> wrote:

> On May 30, 2014, at 5:55 PM, Jameson Nash wrote:
>
>
> I don't see anything wrong.
>
>
> The T in your method declaration is not the same as the T in your function
> declaration
>
>
> What?  I don't understand.  Might be a typo in your sentence.
>
>
> I know that there are four different type variables in the sample code I
> supplied, all named T.  It would have been clearer if I had given them
> distinct names, although that does not seem to be the usual practice in
> Julia.
>
>
> If you are interested in method reflection, I suggest looking at the
> output of methods()....
>
>
> On Friday, May 30, 2014, David Moon wrote:
>
>
> Consider this simplified code:
>
>
> julia> type X{T <: Number} x::T end
>
> julia> f{T}(::X{T}) = 1
>
> julia> XT = methods(f).defs.sig[1]
>
>
> Looks like the output of methods() to me.
>
>
> In any case, here is the real issue, reworded for better clarity:
>
>
> type Y{T} y::T end
>
>
> Y and Y{T} both read back as Y{T}.  And it's not just an issue of print
> formatting, there doesn't seem to be a way to tell those objects apart.
> You can't tell the difference between a TypeVar that was used to declare a
> type, and a TypeVar of a method that was used to parameterize the type.  In
> the implementation, it seems like the parameters field of DataType is being
> overloaded for two different purposes, in one case to remember the
> parameters that are accepted by a generic datatype, in the other case to
> remember the parameters with which a generic datatype was instantiated.
> Shouldn't those two purposes be separated?  But I don't really care about
> how it's implemented, what matters is that the reflection API does not seem
> to give any way tell the difference between Y and Y{T}.
>
>
> As I mentioned in the "Surprising behavior of singleton types" julia-users
> topic, Array{T} reads back as Array{T, N} for the same reason.  Here N is a
> TypeVar that was used to declare the type, while T is a TypeVar of a method
> that was used to parameterize the type.
>
>
> What I don't know is whether this confusion is intentional or a bug.
>
>
> On Jun 1, 2014, at 1:59 AM, Jameson Nash wrote:
>
>
> Array{T} and Array{T,N} describe the same type object
>
>
> I don't see how that can be true.  In one case the number of dimensions is
> a free parameter, in the other it is a static parameter of a method, so
> semantically they are not the same.  They are not the same object by ===
> either.  Here's a little test of object identity, with the typevar names
> changed to avoid ambiguity:
>
>
> julia> f{TT,NN}() = 1
>
> julia> (TT,NN) = methods(f).defs.tvars
>
> julia> Array === Array
>
> true
>
>
> julia> Array{TT} === Array{TT}
>
> true
>
>
> julia> Array{TT,NN} === Array{TT,NN}
>
> true
>
>
> julia> Array{TT} === Array{TT,NN}
>
> false
>
>
> Thanks for filing bug 7062.  I added some information to it which I hope
> will be helpful, not just noise.
>
>

Reply via email to