Hi, Tobias Geerinckx-Rice <m...@tobias.gr> writes:
> Hi Maxim, > > Maxim Cournoyer 写道： >> For some background reading, see [0]. > > Thanks for the well-thought-out reply, and sharing this interesting > link! > > Now, it's just the musings of one person, but now I think I do agree > with (what I think is) the underlying vision: to hush up *unspecified* > and sneakily replace it with true nothingness. OK, I can live with > that. :-) > >> I think the semantic of the language is that it is to be used as the >> lack of a return value from a procedure or syntax, e.g.: >> >> (unspecified? (if #f 'one-arm-if)) -> #t > > Well… in the above context I'd hesitate to even imply > ‘semantics’. It's like undefined behaviour in C. Ascribe it meaning > at your peril. Otherwise, point taken. > >> Having 'unspecified?' even defined in Guile seems to go against that >> idea; perhaps because Wingo themselves seems to disagree in [0]. > > Agreed. *This* was one of my reasons for supporting (field > *unspecified*), so it's nice to have it validated, even if it is > rejected. > >> I'm also thinking 'unspecified being too close to *unspecified* is >> probably going to cause confusion down the line. Reverting to the >> originally used 'disabled may be the lesser evil. > > Ah, here I can concentrate all my previous disagreement: hell no :-) > > It is the worstest evil; literally anything is better than > (enable-foo? 'disabled) defaulting to #t. > > Bikeshed this all y'all want, but 'default or 'unset or 'whatever are > miles better. OK. The v2 and v3 idea ended up not working, among lesser issues :-). So I went with v1, renaming the default value to 'unset; see commit a2b89a3319dc1d621c546855f578acae5baaf6da. Thanks for the naming suggestions. I also added a 'jami-provisioning-partial' system test to ensure it doesn't regress again if we decide to revisit this. Thanks, Closing. Maxim
