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
{{ message }}
This repository has been archived by the owner on Sep 7, 2023. It is now read-only.
define concept A {}
define concept B {}
emit A {};
emit B {};
return;
Emit. B{}
Emit. A{} : ~[multiple][]
Response. unit : Unit
The printed output ~[multiple][] suggests that the inferred type has multiple brands, which is wrong. The reality is that the inferred output type is a branded value with no brands. This is a pathological case but clearly it can happen…
P.S. this works as expected
define concept X {}
define concept A extends X {}
define concept B extends X {}
emit A {};
emit B {};
return;
Emit. B{}
Emit. A{} : X[]
Response. unit : Unit
The text was updated successfully, but these errors were encountered:
define concept A {}
define concept B {}
emit A {};
emit B {};
return
Emit. B{}
Emit. A{} : <>[]
Response. unit : Unit
if true then emit A{}; return else emit B{}; return
Emit. A{} : <>[]
Response. unit : Unit
This prints multiple brands within <> when there is multiple ones, although I don't believe there is a way to create such a type at the moment.
I do like the idea of a Top concept. The issue is whether we would consider different kinds of classes (transaction, event, concept, ...) to be under a Top concept, in which case we can still have the same behavior with:
define concept A {}
define event B {}
emit A {};
emit B {};
return
Emit. B{}
Emit. A{} : <>[]
Response. unit : Unit
The printed output
~[multiple][]
suggests that the inferred type has multiple brands, which is wrong. The reality is that the inferred output type is a branded value with no brands. This is a pathological case but clearly it can happen…P.S. this works as expected
The text was updated successfully, but these errors were encountered: