-
Notifications
You must be signed in to change notification settings - Fork 119
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
Subtyping type parameterization does not work in @multiagent
.
#968
Comments
seems like a problem which should be addressed inside MixedStructTypes.jl (don't really like assignments, but I will solve this soon anyway :D) |
@Tortar before solving anything, can we first please consider a syntax simplification of the macro? Instead of @multiagent struct MultiSchelling{X<:Real}(GridAgent{2})
@agent struct Civilian # can't re-define existing `Schelling` name
mood::Bool = false
group::Int
end
@agent struct Governor{X<:Real} # can't redefine existing `Politician` name
group::Int
influence::X
end
end we could have @multiagent struct MultiSchelling{X<:Real}(GridAgent{2})
@subagent Civilian # can't re-define existing `Schelling` name
mood::Bool = false
group::Int
end
@subagent Governor # can't redefine existing `Politician` name
group::Int
influence::X
end
end two key differences: first, the subtypes do not need |
yes, I like it, but actually there is a reason, the subtypes are not functions, they are types themselves which accept constructor as @multiagent struct MultiSchelling{X<:Real}(GridAgent{2})
@subagent Civilian
mood::Bool = false
group::Int
end
@subagent Governor
group::Int
influence::X
end
end should become @compact_struct_type MultiSchelling{X<:Real} begin
mutable struct Civilian
# fields of gridagent
mood::Bool = false
group::Int
end
mutable struct Governor{X} # -> again X here
# fields of gridagent
group::Int
influence::X
end
end Seems not too difficult to check the presence of a parameter inside each subagent, so this should be doable |
Yes, I agree. Why should we keep |
No, I mean that it is fine not to have it in Agents.jl but I would really keep it in MixedStructTypes.jl which does the heavy lifting and so we need to reconstruct it anyway in the multiagent macro, but this is an implementation detail |
Also actually we need to add a @multiagent struct MultiSchelling{X<:Real}(GridAgent{2})
@subagent Civilian begin
mood::Bool = false
group::Int
end
@subagent Governor begin
group::Int
influence::X
end
end but this seems anyway better |
Actually , thinking what you said that Governor{X} is possible, perhaps we should leave the {X} there as well...? |
yeah, I was in favor of changing this, because has some advantages stemming from the fact that we could really use function and not types for those names, which has some other consequences, but in reality after thinking about this I think that keeping the way it is now is better. So we are just left with the @multiagent struct MultiSchelling{X<:Real}(GridAgent{2})
@subagent Civilian begin
mood::Bool = false
group::Int
end
@subagent Governor{X} begin
group::Int
influence::X
end
end |
okay, and what would happen if a usrer wrote |
Actually, now that I think about it, I am more in favor of not having
and we instruct the users to simply not put type annotations when calling the types. Generally speaking, there shouldn't be any reason to do this, to differentiate via the type parameterization. Right? Or can we imagine a scenario where this is important? |
Tried to imagine something, it is not clear to me when this would be really needed, but in any case, even if we don't mention in the expression of the macro, it will be there anyway, at least for some time, just undocumented, and in general it won't never be really as simple as those functions you wrote, but I think that we don't need to specify everything in details to users |
ok I actually understood when we really need to specify parameters e.g. with a normal struct julia> struct A{T}
x::Union{Int, T}
end
julia> A(1)
ERROR: UndefVarError: `T` not defined
Stacktrace:
[1] A(x::Int64)
@ Main ./REPL[1]:2
[2] top-level scope
@ REPL[2]:1
julia> A{Int}(1)
A{Int64}(1) same happen with MixedStructTypes.jl types |
so the only thing we can really do is changing |
MWE:
erros with
By the way, I find it odd that one must specify the type
X
in both the super type and the subtype. Can't the subtypes remain just a pure name ?The text was updated successfully, but these errors were encountered: