Re: using an SRFI that is not available in Guile

[Attila Lendvai]

using *unspecified* here won't work, because Guile's underlying record
implementation uses it pretty much for the same purpose: it errors
when it encounters *unspecified* as a field value:

> (cfg)
While compiling expression:
Syntax error:
unknown file:761:0: %cfg: missing field initializers (threads) in form (%cfg)

so, i'm back to square one: short of another idea, i'll need srfi-189
for this.


> I see. The ‘define-configuration’ macro uses 'disabled as a way to
> indicate fields that have not been user-specified. Would that be of any
> help in this context?


as discussed already somewhere, regardless of everything else, using
'DISABLED in this context is a bad idea that warrants a patch in
itself; it's super confusing and error prone because configs are full
of boolean fields.


> Another approach would be to use ‘define-record-type*’ and record all
> the default values, including those derived from other fields (just like
> the default ‘home-directory’ field of <user-account> is derived from
> ‘name’.)
>
> Does that make sense?


i think it does, but it would enforce a rather different code
organization. right now i have a function called APPLY-CONFIG-DEFAULTS
that is called at the beginning of each entry point to my service
code. it makes sure that the input config is valid, and returns a new
config object that has the defaults filled in. it has corss-referenced
local variables and even some local functions.

assuming that the evaluation of the default value forms of thunked
fields is delayed until their first access, then forcing this logic
into multiple default forms is possible, but i'd rather not if i can
avoid it.

also, i do want to have the goodies of DEFINE-CONFIGURATION. i used to
use DEFINE-RECORD* before, prior to knowing that D-C was a thing. then
i rewrote my code to use D-C.

maybe i can smarten up DEFINE-CONFIGURATION to (optionally?) use
thunked fields? i'll need to sleep on it.

Ludovic, you're not too happy about the use of extra dependencies
here, right? if so, can you please advise whether i can proceed with
giving srfi-189 a try and see what it looks like (i.e. it's not off
the table to get it accepted)? or do you have any other ideas?

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
Before you speak, let your words pass through three gates:
  At the first gate, ask yourself ‘Is is true?’
  At the second gate ask, ‘Is it necessary?’
  At the third gate ask, ‘Is it kind?’
        — Sufi saying