search

clarity-lang / reference

The Clarity Reference
146 stars 34 forks source link

In-situ Clarity VM upgrades without hard-forks #32

Closed diwakergupta closed 3 years ago

diwakergupta commented 3 years ago

A major consequence of designing Clarity as an on-chain interpreted language is that modifying the language spec would mean modifying the interpreter (VM), which in turn may require a hard fork. But, it turns out that this isn't true for a large class of upgrades that developers would actually want to see -- namely, the introduction of new native functions, with the constraint that they also happen to be entirely expressible in Clarity. Turns out, this covers a lot of native functions!

More details in blockstack/stacks-blockchain#1794

njordhov commented 3 years ago

the introduction of new native functions, with the constraint that they also happen to be entirely expressible in Clarity.

Allowing untyped parameters in private functions #41 is highly relevant for being able to introduce new native functions. It provides more flexibility for expressing new native functions in Clarity, including overloading parameters for multiple types as is done by current native functions. New native function can be almost up to par with the current library rather than have a more restricted argument syntax.

jcnelson commented 3 years ago

This happened in Stacks 2.0. Can we close this?

diwakergupta commented 3 years ago

Yep, implemented as described here: https://github.com/stacksgov/sips/blob/main/sips/sip-006/sip-006-runtime-cost-assessment.md#cost-upgrades