(no title)
weavejester | 4 months ago
The specific problems in the example could be solved by changing how the data is represented. Consider the following alternative representation, written in edn:
{:aws.s3/buckets
{:aws.region/eu-west
{:alpha-hourly {:lifecycle/policy {:delete-after #interval/days 4}}
:alpha-daily {:lifecycle/policy {:delete-after #interval/days 30}}
:alpha-monthly {:lifecycle/policy {:delete-after #interval/days 365}}
:bravo-hourly {:lifecycle/policy {:delete-after #interval/days 4}}
:bravo-daily {:lifecycle/policy {:delete-after #interval/days 30}}
:bravo-monthly {:lifecycle/policy {:delete-after #interval/days 365}}}}}
This prevents issues where the region is mistyped for a single bucket, makes the interval more readable by using a custom tag, and as a bonus prevents duplicate bucket names via the use of a map.Obviously this doesn't prevent all errors, but it does prevent the specific errors that the RCL example solves, all without introducing a Turing-complete language.
MathMonkeyMan|4 months ago
Finding the "right" representation for a given set of data is an interesting problem, but most (all) of the time the representation is specified by someone/something else.
In the past I've written a [preprocessor][1] that adds some power to the representation while avoiding general purpose computation. For example,
Macros, basically. Arithmetic would help there, but that might be too much.[1]: https://github.com/dgoffredo/llama