You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our constraints are complex and unreadable because we lack a name space mechanism (or whatever the right terminology would apply.) Constraints, shorthands, constants etc ... are unaware of where they live. This point was raised early on but never resolved, for intrinsic lisp reasons IIRC. However this question arises anew (for me at least) as our current format will make constraint reading unbelievably tedious and complex for auditors. What can be done about this ?
Some acceptable workarounds would be for instance to have some numerical types with special syntax highlighting e.g.
AccountRowOffset ;; int, make it red
ContextRowOffset ;; int, make it yellow
StorageRowOffset ;; int, make it green
MiscellaneousRowOffset ;; int, make it orange
TransactionRowOffset ;; int, make it blue
E.g. they could be declared with aliases of (defconst ... e.g. (defAccountRowOffset ... and maybe use the syntax highlighting tools to colour names accordingly in the text.
Illustrations
Constraints are unaware of the folder structure so in order to disambiguate we give them long names (this is particularly true in the hub)
we need precise names for various numerical constants as many constants will coincide numerically but not semantically
this complexity is reflected in our constraints but the constraints are unaware of types etc ... making them very hard to read e.g. below the first and only argument of
Main point
Our constraints are complex and unreadable because we lack a name space mechanism (or whatever the right terminology would apply.) Constraints, shorthands, constants etc ... are unaware of where they live. This point was raised early on but never resolved, for intrinsic lisp reasons IIRC. However this question arises anew (for me at least) as our current format will make constraint reading unbelievably tedious and complex for auditors. What can be done about this ?
Some acceptable workarounds would be for instance to have some numerical types with special syntax highlighting e.g.
E.g. they could be declared with aliases of
(defconst ...
e.g.(defAccountRowOffset ...
and maybe use the syntax highlighting tools to colour names accordingly in the text.Illustrations
Similarly the boolean preceing the
MISC_WEIGHT_MMU
is preceded by manually added namespace stuffThe text was updated successfully, but these errors were encountered: