Such ranges are typically used with map and fold. Explicitly enumerating them can be tedious, error-prone, and increases the size of the contract.
It would be beneficial to also generate ranges of bytes such as (range 0x00 0xff) and ranges of characters such as (range "a" "z").
To facilitate static type- and cost analysis, the bounds of the range should be literal or constant. The cost of using range should be the same or less than having an explicitly enumerated range.
this sounds like a great idea, esp since clarity doesn't support loops per se. I see so many similar hacks eg to add an int to a string (to construct a URI) with huge tables of data in the contract.
A
range
function can generate a list of items incrementing from a lower to a higher value.Such ranges are still explicitly enumerated in Clarity contracts. For example, the Pox contract uses a range of numbers for its cycle-indexes:
(let ((cycle-indexes (list u0 u1 u2 u3 u4 u5 u6 u7 u8 u9 u10 u11))) ...
Using
range
would simplify this to:(let ((cycle-indexes (range u0 u11))) ...
Such ranges are typically used with
map
andfold
. Explicitly enumerating them can be tedious, error-prone, and increases the size of the contract.It would be beneficial to also generate ranges of bytes such as
(range 0x00 0xff)
and ranges of characters such as(range "a" "z")
.To facilitate static type- and cost analysis, the bounds of the range should be literal or constant. The cost of using
range
should be the same or less than having an explicitly enumerated range.