AST expression tables can already be generated from plisp sexprs stored in strings via plisp's expr_to_table function. However, the current implementation of expr-to-sexpr which converting in the other direction (AST to sexpr) lacks any kind of indentation, so while the sexprs it generates should be parseable by plisp, they are not human-readable.
Why?
Persistence - saving and sharing. This will be needed once the UI is ready to start manipulating expressions, in order to save them. It will also be needed in order to share them if and when we integrate e.g. norns.online sharing.
Considerations
This may involve some trickery in nested tables.
Associative tables (i.e. non-empty tables where #table == 0) should be changed to (: key1 value1 key2 value2 ...) format.
There is a balance between reducing indentation and number of lines, avoiding long lines (I prefer an 80 char limit but I can be coaxed), and supporting a (yet unestablished) convention. This is mostly up to the implementer.
Taking into account norns screen widths (via e.g. screen.text_extents()) would be ideal. This assumes the expressions will be displayed on the UI. This may not be the case and is completely irrelevant in the case of file persistence - only line length matters there. Could be pulled into a wishlist issue.
Summary
AST expression tables can already be generated from plisp sexprs stored in strings via plisp's
expr_to_table
function. However, the current implementation ofexpr-to-sexpr
which converting in the other direction (AST to sexpr) lacks any kind of indentation, so while the sexprs it generates should be parseable by plisp, they are not human-readable.Why?
Persistence - saving and sharing. This will be needed once the UI is ready to start manipulating expressions, in order to save them. It will also be needed in order to share them if and when we integrate e.g. norns.online sharing.
Considerations
#table == 0
) should be changed to(: key1 value1 key2 value2 ...)
format.screen.text_extents()
) would be ideal. This assumes the expressions will be displayed on the UI. This may not be the case and is completely irrelevant in the case of file persistence - only line length matters there. Could be pulled into a wishlist issue.