> I had used maybe-value-set? because the maybe values are define via the > 'define-maybe' syntax; they are not really part of > 'define-configuration' and are sometimes used outside of it, such as in > (guix home ssh).
oh! i wasn't aware of that. > An exported variable seems simplest and perhaps less awkward to use, > e.g. %unset or similar, although it's a bit ugly that we need to reify > an unspecified value :-). yeah, i started work on implementing an UNSET! function, and its API would be unnecessarily complex with a (type, field-name, instance) signature, and going through generic slot access in its implementation. > prepare a patch for the other things mentionned here (an exported > symbol). i started implementing your suggestions, including the replacement of the scattered usage of (eq? 'unset ...) pattern. what i found is that the code is not very readable using MAYBE-VALUE-SET?, or at least not for me. first, it negates the boolean logic everywhere in the current code (i.e. larger diff, and/or the use of (if (not ...) a b)). and an example wrt readability: (if (maybe-value-set? field-default) field-default (configuration-missing-default-value ...) a value is never set, only places can be set to some value. would you be fine if we renamed MAYBE-VALUE-SET? to UNSET-VALUE? then the boolean logic would remain the same, and the above example would look like: (if (unset-value? field-default) (configuration-missing-default-value ...) field-default) short of a response i'll continue working towards this in the following days and send a proposal eventually, but if you're very much unhappy about it, then let me know! -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- That, which is not falsifiable, can never be true.