> Record Validator > =============================================================================== > > There is also a need to validate records. Matching fields alone do > not actually ensure that the configuration is coherent and > usable. For example, some fields may be mutually incompatible with > others. > > We could provide procedures that validate each record type within > define-configuration itself instead of validating the value at > runtime (i.e. within the body of the service-type).
in my service i have a non-trivial logic regarding defaults (e.g. there are cross-field dependencies while setting some defaults). this means that all the entry points to my service code have a line like this at the very beginning: (set! config (apply-config-defaults config)) maybe this validator logic could be implemented so that the validator may return a new config instance, and all entry points to the service's code would be called with that new instance? > Coalesced documentation > ================================================================ it's a tangential here, but i think demanding a documentation for fields is just wrong. all it does is annoy the programmer who puts an empty "", after wasting some time on a failed compilation. especially in a phase where the code is still in a prototype phase. > Kind of a late realization, but couldn't many of the items above be satisfied > by improvements to define-record-type* instead? > (define-record-type* paired with a documentation literal is nearly equivalent > to define-configuration, > sans the serialization scaffolding) even if so, i'd still maintain a thin layer of abstraction for communicating the intention, and also for possible future extensions. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “He who flatters a man is his enemy. He who tells him of his faults is his maker.” — Confucius (551–479 BC)