Re: Bug with unset variables

[Felipe Contreras <felipe.contreras@xxxxxxxxx>]

On Mon, Nov 23, 2020 at 6:52 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>
> On Mon, Nov 23, 2020 at 3:39 PM Felipe Contreras
> <felipe.contreras@xxxxxxxxx> wrote:
> >
> > My argument is about the consistency from user's perspective.
>
> Consistent from what user's point of view?

Any user.

> One coming to zsh from
> other languages or one long familiar with zsh?  Because zsh
> development has consistently (ahem) sided with the latter.

Users can get accustomed to inconsistent behavior.

The fact that some users have become accustomed to X doesn't mean X is
consistent.

> > 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}
> >   }
>
> In the first case, $var is a global, so the behavior of ${var-other}
> is unknown.  It's not possible to write deterministic code.

You are looking at the half of the picture that is irrelevant.

The behavior of "func foobar" is deterministic, and you know what it will do.

> In the second case, there's a knowable behavior of ${var-other}.  That
> behavior doesn't match your expectation, but it's well-defined.

Nobody is saying it's not well-defined, we are talking about *consistency*.

Only *one* change was added to B, and the behavior changed in *two* ways.

> To make the first function deterministic, it is necessary to write:
>
> func () {
>   unset var
>   [[ -n "$1" ]] && var=$1
>   dosomething ${var-other}
> }
>
> Whether one should expect "typeset var" to imply "unset" is how we
> ended up in this discussion.

The only difference from A to B is that B has a line that says
"declare 'var' as a local variable". That's a fact.

And the behavior of the function changes in two ways (other than what
was told to do). That's also a fact.

It is a fact that the code is doing more than what it was told to do.

If you have an operator called "declare_local_variable", and you do this:

  declare_local_variable var

You run the code, and you find that declare_local_variable does indeed
declare a local variable, but it *also* sets your cat on fire.

You investigate, and you find out the documentation clearly states
that declare_local_variable sets your cat on fire, so the behavior is
"well-defined". But it's not what it says on the tin.

Any normal person would expect such behavior to be enabled by:

  declare_local_variable var
  set_cat_on_fire

And not have to type:

  delcare_local_variable_but_dont_set_cat_on_fire var

Or worse:

  declare_local_variable var
  put_out_fire_from_cat

It doesn't matter how well explained it is in the documentation, or
how many people are accustomed to this behavior, it's still doing
*more* than one thing.

Now, you can call the fact that it's changing the behavior in more
than one way any way you want. When most operators in most languages
do one thing--and one thing only--and this operator does *two* things,
I call that inconsistent.

Maybe there's a better way to describe this fact. Maybe Git's notion
of logically separate changes [1] helps (e.g. you should not mix
whitespace cleanups with functional changes). But the fact is that in
virtually all languages (and bash and ksh) there's an idiom to declare
a local variable and *only* declare a local variable (not do anything
else).

Can we at least agree on that? In zsh typeset does *two* things.

Cheers.

[1] https://git-scm.com/docs/SubmittingPatches

-- 
Felipe Contreras