Incorrect TL-B scheme for Inner Request

[Damtev]

Problem

Consider the following type definition in the TL-B scheme:

actions$_ out_actions:(Maybe OutList) has_other_actions:(## 1) {m:#} {n:#} other_actions:(ActionList n m) = InnerRequest;

This InnerRequest uses an instance OutList type that actually has a type parameter:

out_list$_ {n:#} prev:^(OutList n) action:OutAction = OutList (n + 1);

So, the Inner Request type uses the instance of the OutList type with an unspecified type parameter that cannot be deduced from other type components, making this TL-B scheme incorrect.

Reproduction steps

As a confirmation, running a TL-B schemes parser for this scheme (after adding missing spaces in the end of the line) leads to the following parser error:

error: operator `OutList` applied with incorrect number of arguments, partial type applications not supported
  actions$_ out_actions:(Maybe OutList) has_other_actions:(## 1) {m:#} {n:#} other_actions:(ActionList n m) = InnerRequest;

[tolya-yanot]

yes, mistake in TL-B schema;

Despite the fact that this is not smart contract code, you will get a complimentary bonus if you write the correct version of TL-B scheme.

[Vungun111]

actions$_ out_actions:(Maybe OutList) has_other_actions:(## 1) {m:#} {n:#} other_actions:(ActionList n m) = InnerRequest;

[Vungun111]

error: operator OutList applied with incorrect number of arguments, partial type applications not supported actions$_ out_actions:(Maybe OutList) has_other_actions:(## 1) {m:#} {n:#} other_actions:(ActionList n m) = InnerRequest;

[Vungun111]

outlist$ {n:#} prev:^(OutList n) action:OutAction = OutList (n + 1);

[airaojekhile]

Oh thanks for your complement, but please how can that be done?

On Sat, Jul 13, 2024, 5:33 PM Tolya @.***> wrote:

yes, mistake in TL-B schema;

Despite the fact that this is not smart contract code, you will get a complimentary bonus if you write the correct version of TL-B scheme.

— Reply to this email directly, view it on GitHub https://github.com/ton-blockchain/wallet-contract-v5/issues/18#issuecomment-2226990416, or unsubscribe https://github.com/notifications/unsubscribe-auth/BJWNMMXL4QSNIOZNJUVKZZDZMFJF3AVCNFSM6AAAAABKUZGJEKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRWHE4TANBRGY . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[tochilinak]

yes, mistake in TL-B schema;

Despite the fact that this is not smart contract code, you will get a complimentary bonus if you write the correct version of TL-B scheme.

I am really not sure that it is possible to do without modifying the smart contract code.

I have a hypothesis about TL-B language, but to prove it formally one needs to be more fluent with its grammar than I am. If this is not true, it would be nice to see a counterexample.

The hypothesis: Any TL-B scheme without parameters accepts only a finite number of different Bag of Cells (BOC).

This is true, for example, for hash maps, since they have a parameter that restricts the length of keys.

But for the given scheme of InnerRequest this is not true: it accepts an infinite number of different BOCs. If my hypothesis about TL-B is true, then it is impossible to fix this scheme only in terms of TL-B.

[Totemancer]

The hypothesis: Any TL-B scheme without parameters accepts only a finite number of different Bag of Cells (BOC).

It can represent an infinite number of different BOCs, even without parameters.

Similar approach might work:

actions$_ {n:#} out_actions:(Maybe (OutList n)) has_other_actions:(## 1) {m:#} other_actions:(ActionList n m) = InnerRequest;

https://github.com/Totemancer/w5/commit/b049be79551aafad23d6262cc5a948230164c3cd#diff-c810d7a499cbc0a3c57a9e0fc358d4d6c04241321bbdb2d862e267fbc059befdR26

Can you try and confirm it tochilinak?

Damtev can correct the TL-B above in case got it wrong.

[airaojekhile]

Thanks for trying to help me but please I'd like to confide in you by giving you access to the account to help me do the necessary tasks, if you don't mind?

On Mon, Jul 15, 2024, 12:52 AM Totemancer @.***> wrote:

The hypothesis: Any TL-B scheme without parameters accepts only a finite number of different Bag of Cells (BOC).

It can represent an infinite number of different BOCs, even without parameters.

Similar approach might work:

actions$_ {n:#} out_actions:(Maybe (OutList n)) has_other_actions:(## 1) {m:#} other_actions:(ActionList n m) = InnerRequest;

@.***

diff-c810d7a499cbc0a3c57a9e0fc358d4d6c04241321bbdb2d862e267fbc059befdR26

https://github.com/Totemancer/w5/commit/b049be79551aafad23d6262cc5a948230164c3cd#diff-c810d7a499cbc0a3c57a9e0fc358d4d6c04241321bbdb2d862e267fbc059befdR26

Can you try and confirm it tochilinak?

Damtev can correct the TL-B above in case got it wrong.

— Reply to this email directly, view it on GitHub https://github.com/ton-blockchain/wallet-contract-v5/issues/18#issuecomment-2227524108, or unsubscribe https://github.com/notifications/unsubscribe-auth/BJWNMMRWN4NGJGYRXRTGFJ3ZMMFMRAVCNFSM6AAAAABKUZGJEKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRXGUZDIMJQHA . You are receiving this because you commented.Message ID: @.***>

[tochilinak]

actions$_ {n:#} out_actions:(Maybe (OutList n)) has_other_actions:(## 1) {m:#} other_actions:(ActionList n m) = InnerRequest;

Well, since n and m are 32-bit integers, this scheme also accepts only a finite number of BOCs.

Another problem with this scheme (which is probably more severe) is that the values n and m cannot be deduced by analyzing the root cell. Do TL-B rules allow that? Based on examples from block.tlb I thought that no.

If that was possible, we could define such a scheme:

{n:#} (OutList n) = NewOutList;

Then why would we even need the parameter in OutList?

[tochilinak]

actions$_ {n:#} out_actions:(Maybe (OutList n)) has_other_actions:(## 1) {m:#} other_actions:(ActionList n m) = InnerRequest;

My colleague confirmed that this scheme cannot be parsed with tlbc tool.

However, the following scheme was parsed:

out_list_empty$0 = SomeList;
out_list$1 prev:^SomeList action:OutAction = SomeList;

The problem with this one is that it recursively depends on itself. Is this really a valid definition in TL-B?

[Damtev]

yes, mistake in TL-B schema;

Despite the fact that this is not smart contract code, you will get a complimentary bonus if you write the correct version of TL-B scheme.

It looks like the only way to make this scheme correct is getting rid of type parameters from actions lists, because they cannot be deduced - at least with existing parser. But, unfortunately, it requires changes in the original block.tlb scheme.

[Totemancer]

yes, mistake in TL-B schema; Despite the fact that this is not smart contract code, you will get a complimentary bonus if you write the correct version of TL-B scheme.

It looks like the only way to make this scheme correct is getting rid of type parameters from actions lists, because they cannot be deduced - at least with existing parser. But, unfortunately, it requires changes in the original block.tlb scheme.

There was a pull request from behrang: https://github.com/ton-blockchain/wallet-contract-v5/pull/6

Changes: https://github.com/ton-blockchain/wallet-contract-v5/pull/6/files

Did you try that one too?

[tochilinak]

There was a pull request from behrang: #6

Changes: https://github.com/ton-blockchain/wallet-contract-v5/pull/6/files

Did you try that one too?

actions$_ {n:#} out_actions:(Maybe ^(OutList n)) {m:#} has_other_actions:(Maybe (ActionList m)) = InnerRequest;

Same problem here: n and m cannot be deduced from the root cell.

[Damtev]

There was a pull request from behrang: #6

Changes: https://github.com/ton-blockchain/wallet-contract-v5/pull/6/files

Did you try that one too?

First of all, in this line:

action_list_more$_ {m >= 1} action:ExtendedAction prev:^(ActionList m) = ActionList (m+1);

there are even 2 errors - still missing space in the m + 1 expression and missing type for the m variable.

But anyway, as @tochilinak has already mentioned, in this line

actions$_ {n:#} out_actions:(Maybe ^(OutList n)) {m:#} has_other_actions:(Maybe (ActionList m)) = InnerRequest;

values for the variables n and m still cannot be deduced, so the main problem remains.

[Dlibl]

g p