Re: Bug with unset variables

[Felipe Contreras <felipe.contreras@xxxxxxxxx>]

On Mon, Nov 23, 2020 at 2:26 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>
> On Sun, Nov 22, 2020 at 11:27 PM Felipe Contreras
> <felipe.contreras@xxxxxxxxx> wrote:
> >
> > Nope. I demonstrated how they are functionally the same with plenty of examples.
>
> All of your examples are from other languages.

"It" in this case is code from Python compared with code from shell
which is functionally the same, that is to say: it does the same
thing.

Of course it's from other languages. That's precisely what is being compared.

> > But then you used an historic argument to counter my claim that Zsh
> > was not consistent.
>
> The historic reference was for context.  The actual argument is that
> zsh is consistent because the behavior of variables inside function
> scope mirrors that of variables at global scope.  History is merely
> why variables behave that way at global scope.

You used history to explain what was the most straightforward way to
implement the new feature without much architectural changes in zsh.

This does not imply it was the best way to do it, nor does it show it
is consistent from the user's point of view, because it's 100%
dependent on the implementation of the shell.

> Your argument is that zsh was wrong to adopt that interpretation of
> variables in function scope.  That doesn't make it (internally)
> inconsistent, it just makes it different.

I did not argue it was internally inconsistent.

I grant you--after looking at the code--the change was likely
internally consistent.

My argument is about the consistency from user's perspective.

This is the example I gave to Roman, which went completely unresponded:

  func () {
    [[ -n "$1" ]] && var=$1
    dosomething ${var-other}
  }

  func () {
    typeset var
    [[ -n "$1" ]] && var=$1
    dosomething ${var-other}
  }

> > I argued it makes sense to add a setopt option that turns on the
> > behavior that a) in my opinion is more consistent, b) is what Bash and
> > ksh does, and c) is the equivalent of what virtually all languages do.
>
> That's where we could have been ten days ago, but you said (of
> changing the default) ...
>
> "Nothing is impossible. It's just harder when you don't even think of
> trying it."

Yes, that was in response to you saying it was infeasible to change the default.

I argued that nothing is impossible. It may be infeasible in the final
analysis, but maybe not, the only way we could know is if it's tried
first (with an option).

So it's perfectly consistent to argue both: a) a setopt option makes
sense now, and b) eventually this option can be considered to be the
default and it's not necessarily completely infeasible.

> ... so we've been down the rabbit hole of arguing necessary/desirable.
>
> To hopefully tie this off, does anyone want to argue for a new option
> instead of adding this to KSH_TYPESET?

Not me. I'd say any way to enable this mode would be fine, and if
there's no conflict with KSH_TYPESET, that sounds like a sensible
option.

Cheers.

-- 
Felipe Contreras