You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An alias definition stores the raw type expression, but does not immediately resolve that type expression until the alias is used somewhere. In the main semantic phase this should be fine, but in the top-level phase not all types are defined yet, which means syntactically identical aliases can mean different things depending on require order, macros, or overload ordering (#11678 shows how Number::Primitive is prone to this):
This behavior is confusing in both user code and the compiler's own source code. I propose that we disallow those alias definitions in the future, so every alias definition must be resolved immediately:
classFooaliasBar=Foo# `Foo::Bar` refers to `::Foo`, nothing written here will change thataliasBaz=Fooo# Undefined constant FoooaliasBaz=Array(Fooo) # Undefined constant Foooend
A direct consequence is that mutually recursive aliases (#7704) are no longer possible, since the first alias must reference some yet undefined alias:
# aliases referencing each otheraliasA1=Int32|Hash(A1, B1) # Error: undefined constant B1aliasB1=String|Hash(B1, A1)
# these mutually recursive aliases reference each other only indirectly,# even though each type expression alone would suggest otherwisealiasA2=Int32|Hash(B2, C2) # Error: undefined constant B2aliasB2=String|Hash(C2, A2)
aliasC2=Char|Hash(A2, B2)
Now consider a self-recursive alias:
moduleFooaliasFoo=Int32|Array(Foo)
end
The Foo on the right-hand side must refer to ::Foo::Foo in case of a self-recursive alias, or the module ::Foo if recursive aliases are completely disallowed (#5155). Self-recursive types are fixable, and a great variety of FP languages have them after all, so I think they could stay for the moment. Having at most one recursive element means this recursive alias should behave like what one would call μX . Int32 | Array(X) in academic research.
The text was updated successfully, but these errors were encountered:
An alias definition stores the raw type expression, but does not immediately resolve that type expression until the alias is used somewhere. In the main semantic phase this should be fine, but in the top-level phase not all types are defined yet, which means syntactically identical aliases can mean different things depending on require order, macros, or overload ordering (#11678 shows how
Number::Primitive
is prone to this):This behavior is confusing in both user code and the compiler's own source code. I propose that we disallow those alias definitions in the future, so every alias definition must be resolved immediately:
A direct consequence is that mutually recursive aliases (#7704) are no longer possible, since the first alias must reference some yet undefined alias:
Now consider a self-recursive alias:
The
Foo
on the right-hand side must refer to::Foo::Foo
in case of a self-recursive alias, or the module::Foo
if recursive aliases are completely disallowed (#5155). Self-recursive types are fixable, and a great variety of FP languages have them after all, so I think they could stay for the moment. Having at most one recursive element means this recursive alias should behave like what one would callμX . Int32 | Array(X)
in academic research.The text was updated successfully, but these errors were encountered: