Open Damtev opened 1 month ago
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.
actions$_ out_actions:(Maybe OutList) has_other_actions:(## 1) {m:#} {n:#} other_actions:(ActionList n m) = InnerRequest;
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;
outlist$ {n:#} prev:^(OutList n) action:OutAction = OutList (n + 1);
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: @.***>
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.
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;
Can you try and confirm it tochilinak?
Damtev can correct the TL-B above in case got it wrong.
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
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: @.***>
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
?
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?
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.
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?
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.
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.
g p
Problem
Consider the following type definition in the TL-B scheme:
This
InnerRequest
uses an instanceOutList
type that actually has a type parameter:So, the
Inner Request
type uses the instance of theOutList
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: