Allow calling a different instance of the current contract #870

2022-04-29T02:56:12+09:00

ghallak commented

2022-04-29 02:56:12 +09:00

(Migrated from gitlab.com)

Fixes: #301, Fixes: #380

zxq9 commented

2022-05-02 16:37:47 +09:00

(Migrated from gitlab.com)

Created by: hanssv

Looks promising - test failing?

*Created by: hanssv* Looks promising - test failing?

ghallak commented

2022-05-02 22:52:08 +09:00

(Migrated from gitlab.com)

The tests are failing because of this https://gitlab.com/gajumaristas/aesophia/-/issues/380 which I'm working on fixing in this PR as well.

zxq9 commented

2022-05-05 16:41:38 +09:00

(Migrated from gitlab.com)

Created by: hanssv

Review: Dismissed

Looks good!

Maybet add an update to the CHANGELOG?

*Created by: hanssv* **Review:** Dismissed Looks good! Maybet add an update to the CHANGELOG?

ghallak commented

2022-05-05 17:02:49 +09:00

(Migrated from gitlab.com)

@hanssv I have updated the CHANGELOG here d84960274caca96e7b45c66870e3322c81aa6612

zxq9 commented

2022-05-08 18:29:38 +09:00

(Migrated from gitlab.com)

Created by: radrow

Ability? Possibility doesn't fit here imo

*Created by: radrow* Ability? Possibility doesn't fit here imo

zxq9 commented

2022-05-08 18:30:08 +09:00

(Migrated from gitlab.com)

Created by: radrow

- The ability possibility to call different instance of the current contract

*Created by: radrow* ```suggestion:-0+0 - The ability possibility to call different instance of the current contract ```

zxq9 commented

2022-05-08 18:33:28 +09:00

(Migrated from gitlab.com)

Created by: radrow

these could be separate functions

*Created by: radrow* these could be separate functions

zxq9 commented

2022-05-08 18:44:11 +09:00

(Migrated from gitlab.com)

Created by: radrow

Do you really need to rebind it? I would expect the "untyped" version to unify to the final "typed" representation anyway. Do you check if they match?

*Created by: radrow* Do you really need to rebind it? I would expect the "untyped" version to unify to the final "typed" representation anyway. Do you check if they match?

ghallak commented

2022-05-09 16:58:16 +09:00

(Migrated from gitlab.com)

Done here d11e471bc2718356401a0444f5ae38ecaf3165be

ghallak commented

2022-05-09 17:17:27 +09:00

(Migrated from gitlab.com)

If I don't rebind, the cases with type aliases will fail, since they are only replaced during the type inference.

ghallak commented

2022-05-09 17:25:03 +09:00

(Migrated from gitlab.com)

Done here dba72071120f798a6174e64e286df0a0e828913c

zxq9 commented

2022-05-10 05:47:59 +09:00

(Migrated from gitlab.com)

Created by: radrow

Could you give me some example? I also wonder if this could be hacked around somehow (that is, so both versions don't really match)

*Created by: radrow* Could you give me some example? I also wonder if this could be hacked around somehow (that is, so both versions don't really match)

ghallak commented

2022-05-18 16:56:41 +09:00

(Migrated from gitlab.com)

This is one example:

contract interface Remote =
  record rstate = { i : int, s : string, m : map(int, int) }

  entrypoint fun_update_i  : (rstate, int) => rstate

contract StateHandling =

  type state = Remote.rstate

  entrypoint init(r : Remote, i : int) =
    let state0 = { i = 0, s = "undefined", m = {} }
    r.fun_update_i(state0, i)

The problem here is that the type of the arguments in the fun_update_i function declaration is set to rstate before the type inference and to Remote.rstate after the type inference (because the qualifications are added during type inference).

Binding the fields only before the type inference, would cause an error that the types rstate and Remote.rstate cannot be unified.

I can't currently think of a solution for this, so I may add a comment about it and maybe it can be handled later, unless you can think of a solution for this?

This is one example: ``` contract interface Remote = record rstate = { i : int, s : string, m : map(int, int) } entrypoint fun_update_i : (rstate, int) => rstate contract StateHandling = type state = Remote.rstate entrypoint init(r : Remote, i : int) = let state0 = { i = 0, s = "undefined", m = {} } r.fun_update_i(state0, i) ``` The problem here is that the type of the arguments in the `fun_update_i` function declaration is set to `rstate` before the type inference and to `Remote.rstate` after the type inference (because the qualifications are added during type inference). Binding the fields only before the type inference, would cause an error that the types `rstate` and `Remote.rstate` cannot be unified. I can't currently think of a solution for this, so I may add a comment about it and maybe it can be handled later, unless you can think of a solution for this?

zxq9 commented

2022-05-25 02:08:36 +09:00

(Migrated from gitlab.com)

Created by: radrow

Maybe forcefully qualify all the types at every opportunity, so there is always Remote.rstate?

*Created by: radrow* Maybe forcefully qualify all the types at every opportunity, so there is always `Remote.rstate`?

zxq9 commented

2022-10-23 20:18:33 +09:00

(Migrated from gitlab.com)

Created by: radrow

Review: Approved

*Created by: radrow* **Review:** Approved

zxq9 commented

2022-10-23 20:28:06 +09:00

(Migrated from gitlab.com)

Created by: hanssv

Review: Approved

*Created by: hanssv* **Review:** Approved

zxq9 commented

2022-10-23 21:01:29 +09:00

(Migrated from gitlab.com)

Merged by: ghallak at 2022-10-23 12:01:29 UTC

*Merged by: ghallak at 2022-10-23 12:01:29 UTC*

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: QPQ-AG/sophia#870