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(compiler)!: Prohibit mutating options [LNG-277] #960

Merged
merged 30 commits into from Nov 13, 2023

Conversation

InversionSpaces
Copy link
Contributor

@InversionSpaces InversionSpaces commented Nov 3, 2023

Description

Forbid declaring options like streams and mutating them.

Proposed Changes / Implementation Details

  • Rework parsing - allow any combination of array, streams and options
  • Enhance type resolving system in semantics layer
  • Rework type system: allow only DataType as elements of streams

Checklist

  • Corresponding issue has been created and linked in PR title.
  • Proposed changes are covered by tests.
  • Documentation has been updated to reflect the changes (if applicable).
  • I have self-reviewed my code and ensured its quality.
  • I have added/updated necessary comments to aid understanding.

Reviewer Checklist

  • Tests have been reviewed and are sufficient to validate the changes.
  • Documentation has been reviewed and is up to date.
  • Any questions or concerns have been addressed.

Copy link

linear bot commented Nov 3, 2023

LNG-277 Prohibit mutating options

Right now it is possible to define options just like streams and mutate them:

maybe_value: ?string
...
maybe_value <<- value

It is documented in docs and used a lot in aqua code.

But option implicitly canonicalized on return, making them immutable:

func create_option() -> ?string:
  option: ?string
  option <<- "value"
  <- option

o <- create_option()
o <<- "new value" -- Error here

Also if a function accepts an option, it is prohibited to mutate it:

func use_option(option: ?string):
  option <<- "default value" -- Error here

Moreover, there is no guarantee that option will actually contain at most one element (bc under the hood it is an array or a stream), except that for immutable options compiler will reject non-zero index access:

func use_option():
  option: ?string
  a = option[10] -- OK, which is strange

func use_option(option: ?string):
  a = option[10] -- Error here

Also, streams are implicitly convertable (canonicalized) to options, so popular usage pattern is supported by them:

func create_option() -> ?string:
  option: *string
  option <<- "value"
  <- option

Everything described above makes options inconsistent data type, complicating compiler and aqua code. This is why it seems better to:

  • prohibit creating options with o: ?type syntax
  • prohibit mutating options everywhere

@InversionSpaces InversionSpaces added the e2e Run e2e workflow label Nov 7, 2023
@InversionSpaces
Copy link
Contributor Author

Also fixes LNG-270

@InversionSpaces InversionSpaces marked this pull request as ready for review November 8, 2023 17:05
@InversionSpaces InversionSpaces merged commit 68425ed into main Nov 13, 2023
11 checks passed
@InversionSpaces InversionSpaces deleted the feat/immutable-options-LNG-277 branch November 13, 2023 08:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
e2e Run e2e workflow
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants