Allow Module as type parameters #47749
Conversation
There was a problem hiding this comment.
SGTM. Can you add a hash field (or otherwise make the hash something stable like hash(m->parent, hash(m->name, hash)) so that the type caches don't get corrupted when we load incremental files.
If I am reading the code correctly, there is a bit of discrepancy about where you added it in tfuncs (equivalent to is_nestable_type_param) vs builtins.c (approximately valid_tparam)
base/hashing.jl
Outdated
| @@ -114,3 +114,9 @@ function hash(s::String, h::UInt) | |||
| h += memhash_seed | |||
| ccall(memhash, UInt, (Ptr{UInt8}, Csize_t, UInt32), s, sizeof(s), h % UInt32) + h | |||
| end | |||
|
|
|||
| function hash(m::Module, h::UInt64) | |||
There was a problem hiding this comment.
Instead of adding this, we should make objectid use the module's UUID.
There was a problem hiding this comment.
I don't think we can do that currently. The UUID is mutable.
There was a problem hiding this comment.
We will have to solve that --- adding a julia hash method doesn't help because the type system and cache won't call it. I suppose this algorithm could be put into objectid for now though.
There was a problem hiding this comment.
Ah, I see you did that already. So this method can just be removed.
Keno
force-pushed
the
kf/allowmoduletparam
branch
from
1870342 to
161acbb
Compare
Keno
changed the title
Keno
force-pushed
the
kf/allowmoduletparam
branch
from
161acbb to
a254dcc
Compare
Can be used in place of the macro to give a pass CassetteoOverlay behavior. The abstract type works by reading the appropriate binding from the type parameter. Requires JuliaLang/julia#47749
Can be used in place of the macro to give a pass CassetteoOverlay behavior. The abstract type works by reading the appropriate binding from the type parameter. Requires JuliaLang/julia#47749
|
Does this let you dispatch on modules? E.g. can I write: struct Foo{M}
end
f(x::Foo{<:CSV}) = ...
f(x::Foo{<:DataFrames}) = ... |
|
yes |
The intended use case for this is generated functions that want to generate some reference to a module-specific generic function. The current solution is to duplicate the generated function into every module (probably using a package-provided macro) or to have some sort of registry system in the package providing the generated function. Both of these seem a bit ugly and I don't think there's any particularly good reason not to allow Modules to be type parameters. Admittedly, modules are not part of the scope contemplated by #33387 as they are mutable, but I think the mental model of modules is that they're immutable references to a namespace and what's actually mutable is the namespace itself (i.e. people wouldn't expect two modules that happen to have the same content be `==`). This makes me think it still fits the mental model.
Keno
force-pushed
the
kf/allowmoduletparam
branch
from
a254dcc to
93b9aa8
Compare
|
Without the |
|
Broke the gcext test |
|
why is that allow-fail if you expect it to be noticed? |
|
Because we only recently wired it up and we have to backport some things to 1.9 before we can make it mandatory... |
|
Can we make it conditional on branch name? |
|
Yeah, it's very easy to have different Buildkite configs for different branches. Currently, 1.8 has its own config. Currently, 1.9 and master have the same config (just for convenience), but we can split them whenever we want. cc: @staticfloat |
|
#47383 may have broken @nanosoldier |
|
Your benchmark job has completed - successfully executed benchmarks. A full report can be found here. |
This was an oversight in the implementation of #47749 and caused spurious asserts in debug mode: ``` julia> struct Foo{A, B}; end julia> Foo{Base} julia-debug: /home/keno/julia/src/builtins.c:350: type_object_id_: Assertion `!tv->name->mutabl' failed. ```
This was an oversight in the implementation of #47749 and caused spurious asserts in debug mode: ``` julia> struct Foo{A, B}; end julia> Foo{Base} julia-debug: /home/keno/julia/src/builtins.c:350: type_object_id_: Assertion `!tv->name->mutabl' failed. ```
This was an oversight in the implementation of JuliaLang#47749 and caused spurious asserts in debug mode: ``` julia> struct Foo{A, B}; end julia> Foo{Base} julia-debug: /home/keno/julia/src/builtins.c:350: type_object_id_: Assertion `!tv->name->mutabl' failed. ```
The intended use case for this is generated functions that want to generate some reference to a module-specific generic function. The current solution is to duplicate the generated function into every module (probably using a package-provided macro) or to have some sort of registry system in the package providing the generated function. Both of these seem a bit ugly and I don't think there's any particularly good reason not to allow Modules to be type parameters. Admittedly, modules are not part of the scope contemplated by #33387 as they are mutable, but I think the mental model of modules is that they're immutable references to a namespace and what's actually mutable is the namespace itself (i.e. people wouldn't expect two modules that happen to have the same content be
==). This makes me think it still fits the mental model.