Re: Brainstorming ideas for define-configuration

[Attila Lendvai <attila@lendvai.name>]

> 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)