accordproject / ergo

Programming Language for Smart Legal Contracts
https://accordproject.org/projects/ergo
Apache License 2.0
157 stars 55 forks source link

Printing branded values with no brands is wrong #420

Open kach opened 6 years ago

kach commented 6 years ago
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
kach commented 6 years ago

If we had a "top" concept, then that could be the brand printed in this case. This would also help fix #387 I think.

jeromesimeon commented 5 years ago

WIP:

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.

jeromesimeon commented 5 years ago

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