Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: new functions in stdlib from stdlib.fc and math.fc #986

Open
wants to merge 27 commits into
base: main
Choose a base branch
from

Conversation

Gusarich
Copy link
Member

@Gusarich Gusarich commented Oct 25, 2024

Issue

Closes #770, closes #1029

Checklist

  • I have updated CHANGELOG.md
  • I have documented my contribution in docs/ and made the build locally
  • I have added tests to demonstrate the contribution is correctly implemented: this usually includes both positive and negative tests, showing the happy path(s) and featuring intentionally broken cases
  • I have run all the tests locally and no test failure was reported
  • I have run the linter, formatter and spellchecker
  • I did not do unrelated and/or undiscussed refactorings

Current State

  • All stdlib.fc functions are present in Tact stdlib in some form, with some exceptions:
    • no tuple manipulation functions, because there is no tuple support in Tact. Do we really need them? @anton-trunov
    • no minmax and no slice_bits_refs because we don't have tensor types in Tact and it would be useless: Tensor types #1116
    • no set_data and get_data because Tact manages persistent storage by itself
    • no bless and other continuation functions because Tact manages control flow itself and for running some arbitrary code it's better to use RUNVM which doesn't require continuations parameters
    • no raw_reserve_extra because it requires an uint32 -> varuint32 dictionary and we only support varuint16 for values currently: VarUInt32, VarInt16, VarInt32 serialization types #1117
  • All mathlib.fc functions are present in Tact stdlib in some form, with some exceptions:
    • no fixed-point arithmetic related functions: Fixed-point arithmetics library #1118
    • no nan and is_nan because we don't support NaN in Tact. Do we really need them? @anton-trunov
    • no sub_rev because it is useless in our case
    • no ...MOD instructions because they return two values as a tensor and it won't be very developer-friendly in Tact to make them return tuples in my opinion: Tensor types #1116
  • All new functions are covered with tests

@Gusarich Gusarich added this to the v1.6.0 milestone Oct 25, 2024
Copy link
Member

@novusnota novusnota left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for reviewing the draft, I just wanted to keep those notes around :)

stdlib/stdlib.fc Outdated Show resolved Hide resolved
stdlib/stdlib.fc Outdated Show resolved Hide resolved
stdlib/stdlib.fc Show resolved Hide resolved
stdlib/std/math.tact Outdated Show resolved Hide resolved
stdlib/std/cells.tact Outdated Show resolved Hide resolved
stdlib/std/cells.tact Outdated Show resolved Hide resolved
stdlib/std/cells.tact Outdated Show resolved Hide resolved
stdlib/std/cells.tact Outdated Show resolved Hide resolved
@Gusarich Gusarich force-pushed the stdlib-extension-with-mathlib branch from 178e712 to b9b6206 Compare November 17, 2024 07:41
@Gusarich
Copy link
Member Author

@novusnota @anton-trunov Implemented all functions. I'd like to hear some intermediate feedback on them before I proceed with writing tests.

I made sure to include all missing functions from both stdlib.fc and mathlib.fc with some exceptions (see PR description).

Copy link
Member

@anton-trunov anton-trunov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

afair, mathlib.fc has lots of functions for fixed-arithmetic as well, I think we should add those too (perhaps as a separate library, like fixed_point_math.tact).

Also, I left a couple comments in the source code

CHANGELOG.md Outdated Show resolved Hide resolved
refs: Int;
}

asm fun computeDataSize(cell: Cell, maxCells: Int): DataSize { CDATASIZE TRIPLE }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would TRIPLE work here? Structures are returned as tensors, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TRIPLE makes three elements into a tuple of length 3. I think it should work

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, but our structs are tensors, not tuples, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

structs are implemented as tuples in Tact (that's why we had problems with long ones in the first place, remember?)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, I must have mistaken it with the unbundled approach in the storage

stdlib/std/math.tact Outdated Show resolved Hide resolved
ctx.asm("", "UBITSIZE");
});

ctx.fun(`__tact_sqrt`, () => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how about we implement this in Tact?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and what about other stdlib functions?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if a function can be implemented efficiently in Tact, we should implement it in Tact or open an issue and fix it

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

CHANGELOG.md Outdated Show resolved Hide resolved
@Gusarich Gusarich marked this pull request as ready for review November 28, 2024 05:21
@Gusarich Gusarich requested a review from a team as a code owner November 28, 2024 05:21
@Gusarich
Copy link
Member Author

@anton-trunov @novusnota covered all new functions with tests!

Found and fixed a few little mistakes in types (for addressNone and computeDataSize functions). Also added comments with formulas for new math functions

@anton-trunov
Copy link
Member

@Gusarich Let's

  • resolve the merge conflicts
  • move the notes from "current state" to their own separate issues

@anton-trunov anton-trunov self-assigned this Nov 28, 2024
Copy link
Member

@anton-trunov anton-trunov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should document the new functions in https://docs.tact-lang.org/ref/core-math and other relevant doc pages

@novusnota
Copy link
Member

We should document the new functions in https://docs.tact-lang.org/ref/core-math and other relevant doc pages

Will do

@Gusarich Gusarich force-pushed the stdlib-extension-with-mathlib branch from 8a5fed9 to 734f3a0 Compare November 29, 2024 12:53
@Gusarich
Copy link
Member Author

@anton-trunov rebased

}

get fun addressNone(): Address? {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does it return "Maybe Address" and not "Address" ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because the way Tact currently work with addresses is that "null" as an address is actually addressNone

Copy link
Contributor

@Shvandre Shvandre Dec 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I checked the sources and you are 100% right, but maybe we should change it?
Or change the tlb schemes generation, because

struct Test {
    my_addr: Address?;
}

results

## Test
TLB: `_ my_addr:Maybe address = Test`
Signature: `Test{my_addr:Maybe address}`

In .md file (and maybe in some other places)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's an old problem in Tact, which was blocking multiple issues in the past. I remember some old comments in address-related issues about that.

My opinion is that we should rework addresses, because currently the way they work is not intuitive and doesn't fit into how other types work.
Basically, addr_none should be a valid part of Address type and should be checked by devs against addressNone() (and not null). And Address? should mean Maybe Address, which also could contain addr_none.
@anton-trunov what do you think?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

addr_none should be a valid part of Address type and should be checked by devs against addressNone() (and not null).

yeah, this is how it should work, indeed

And Address? should mean Maybe Address

also agreed

which also could contain addr_none.

this one I'm not sure about, I'd say addr_none in the optional version should be 000, what do you think?

Copy link
Member Author

@Gusarich Gusarich Dec 2, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this one I'm not sure about, I'd say addr_none in the optional version should be 000, what do you think?

well yes, that's what I meant. I was talking about the possibility of the case when value of Address? is equal to addressNone().

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Gusarich Maybe you could take care of this change first (allowing addr_none as an inhabitant of the Address type) and then we merge this PR with the corresponding changes

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could also probably add a config option to turn off address verification along the way

@Shvandre Shvandre self-requested a review December 1, 2024 13:20
Shvandre
Shvandre previously approved these changes Dec 1, 2024
@novusnota
Copy link
Member

novusnota commented Dec 1, 2024

We should document the new functions in https://docs.tact-lang.org/ref/core-math and other relevant doc pages

Halfway there, will be finishing this soon.

UPD: 2/3rds are done, got to complete the cell related functions
UPD: done!

@Gusarich
Copy link
Member Author

Gusarich commented Dec 5, 2024

move the notes from "current state" to their own separate issues

@anton-trunov have a look at the updated notes. there are few of them that I don't think we need to cover in Tact

@anton-trunov
Copy link
Member

Looks good! Thanks for adding those

@novusnota
Copy link
Member

@anton-trunov @Gusarich

Added documentation for all of the new functions from this PR, except for the addressNone(), since its implementation is still in the works. Didn't add doc comments yet — once we agree on the descriptions in the documentation, then I'll quickly add the doc comments mirroring them.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we want to also add muldiv?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add myCode and addressNone to stdlib Port stdlib.fc and mathlib.fc's asm functions to Tact's stdlib
4 participants