Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

call overloading, and make constructors use it #8712

Merged
merged 53 commits into from
Oct 23, 2014

Conversation

JeffBezanson
Copy link
Member

Behold, after a week of red Xes, the tests are passing.

This replaces #8008 and also redesigns constructors to use call overloading instead of having some types magically also be generic functions.

An inner constructor looks like

call{T}(::Type{MyType{T}}, args...) = ...

and an outer constructor looks like

call{T}(::Type{MyType}, x::T) = MyType{T}(x)

Now you can also have things that are in-between, for example this SubArray constructor:

    function call{T,A<:Array,I<:(Any,)}(::Type{SubArray{T,0,A,I}}, p::A, i::(Int,))
        new{T,0,A,I}(p, i, (), Int[], i[1])
    end

Notice new{...} has been added and is needed in cases like this.

Of course, you can also define constructors for abstract types which should be helpful in several cases that have come up over time.

An interesting side effect of this change is that this:

convert{T}(::Type{T}, x::T) = x

now correctly implements "conversions" to supertypes (e.g. convert(Number, 1)).


This raises several interesting discussion questions that have not been resolved yet:

  • How should method reflection work? Do we preserve the illusion that types are "callable"?
  • What to do with the Callable type? Maybe make Function an abstract type instead?
  • How do we make call fall back to convert, and also to call in lower-level modules (see WIP: Call overload #8008 (comment))?
  • We can now remove the dreaded "lower-case" conversion functions, but should Int8(x) be vectorized?

stevengj and others added 30 commits August 12, 2014 14:16
…call(f, x...) as a fallback (if f is not a function); to do: update inference, fallback to call when f is a type
Conflicts:
	src/codegen.cpp
	test/core.jl
- look up call in the right module instead of using jl_call_func
- some inference support for call overloading
- pass `call` to _apply and kwcall so they use the containing module's definition
- deprecate explicit apply(), rename the builtin to _apply
this does not work yet, but gets past the first bootstrap stage.

so far this is a significant net simplification.
REPL now works with sys0.ji
…pes in Base

this allows the full build to go through
- make typeintersect((Rational{T},T),(Rational{Integer},Int)) == (Rational{Integer},Int)
  This used to be Bottom, since the T's had to match exactly. Now if T
  appears in covariant position, subtypes can also match. This is a
  good change anyway, but turns out to be necessary for the new constructor
  design. We have a constructor `Rational{T}(x::T, y::T)` which now gets
  lowered to `call{T}(::Type{Rational{T}}, x::T, y::T)`, so obviously we
  must allow x and y to be any subtypes of T.
  This also allows convert_default to be replaced with
  `convert{T}(::Type{T}, x::T) = x` (to be done next).

- making that work required an improved constraint solving algorithm in
  type intersection. the new algorithm should be much more robust, but
  it yields more typevars in its answers, for example
  `typeintersect((T,AbstractArray{T}),(Any,Array{Number,1}))` gives
  `(_<:Number,Array{Number,1})`.

  Hopefully this will not cause problems. But I can imagine doing a
  post-processing step to replace `_<:T` in covariant position with
  just `T`. In the meantime, to further legitimize such results I
  also made the next change:

- make TypeVar a subtype of Type
another Core.convert method to prevent types from old Base from leaking in
@JeffBezanson JeffBezanson deleted the jb/call_constructors branch October 25, 2014 17:14
stevengj added a commit to stevengj/julia that referenced this pull request Oct 31, 2014
@ViralBShah
Copy link
Member

I don't think this is documented yet, but I might have missed it. If it indeed needs to be done, I guess we should open a new issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.