Re: More rabbit-holes with unset variables

[Felipe Contreras <felipe.contreras@xxxxxxxxx>]

On Fri, Nov 27, 2020 at 4:39 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>
> On Fri, Nov 27, 2020 at 2:10 PM Felipe Contreras
> <felipe.contreras@xxxxxxxxx> wrote:
> >
> > So we can interpret what you said as 'so the only useful "declared but
> > not set" variable is a string' without losing any meaning.
>
> That's not correct, but again I was hoping it wasn't necessary to
> spell all this out.
>
> All of the following create parameters representing strings, none of
> which are useful unless they either have a default or the "preserve
> when not set" behavior applies:

These are not contradictory unless you commit the fallacy of the converse.

"All animals that bark are mammals" doesn't mean "all mammals bark".

Analogously:

"All unset variables that are useful are strings" doesn't mean "all
strings are unset variables that are useful".

To be pedantic: param_is_useful_unset(p) -> param_type_is_string(p).
Not the other way around.

This is a bit tautological, because if the variable is unset, it can't
be anything else but a string: param_is_unset(p) ->
param_type_is_string(p).

Cheers.

-- 
Felipe Contreras