Re: [vim/vim] patch 8.2.1506: Vim9: no error when using a number other than 0 or 1 as bool (d70840e)

[Brett Stahlman]

What is the reason for this change? Will this not break many scripts that rely upon the traditional C approach of treating any nonzero value as true in a boolean context?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

[Bram Moolenaar]

Brett Stahlman wrote:

> What is the reason for this change? Will this not break **many**

> scripts that rely upon the traditional C approach of treating any
> nonzero value as true in a boolean context?

Not really. If we make it very strict only true and false would be
valid. We tried this at first, but some builtin functions return zero
or one for false and true. Changing the return value depending on
whether it's used in legacy script or Vim9 script gets very tricky.
So currently we allow using zero for false and one for true. The tests
were corrected for this, and it looks good.

Allowing for other numbers leads to mistakes. E.g. when using "-1",
is that false or true? And using 9999 for true doesn't make sense, it
is probably a mistake.

Note that in conditions, where the expression is clearly either
evaluating to false or true, the rules are less strict. This follows
what TypeScript is doing.

So this works:
vim9script
let number = 999
if number
echo 'number is not zero'
endif

But this doesn't:
vim9script
let number = 999
let flag: bool = number

Thus when used as a condition a non-zero value is truthy. When used as a
value only zero and one are assignable to a boolean variable.

There is a balance between very strict type checking and very loose type
checking (or none at all). We'll see if the current choice works out.
So far it looks good.

--
"You're fired." (1980)
"You're laid off." (1985)
"You're downsized." (1990)
"You're rightsized." (1992)
(Scott Adams - The Dilbert principle)

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Brett Stahlman]

Allowing for other numbers leads to mistakes. E.g. when using "-1", is that false or true? And using 9999 for true doesn't make sense, it is probably a mistake.

I guess because I've mostly programmed in C/C++, I think of any nonzero value as truthy. That just feels idiomatic and natural to me. For instance, if I had a variable intended to hold a line number (or zero to signify undefined), I would think it natural to treat the line number variable as a boolean to test for definedness. But I realize this sort of thing is often frowned upon in modern, strongly typed languages...

I didn't realize things would still work as before when the variable is used in a conditional. (A plugin user reported that the change was breaking something in a plugin I've contributed to, and I haven't actually tested with the latest version of Vim.)

Would the "want_bool" flag be true if unary '!' is used to force interpretation of a variable as a boolean? E.g., will something like this continue to work as before?

let valid_line_nr = !!line_nr
if valid_line_nr
    ...
endif

[Bram Moolenaar]

Brett Stahlman wrote:

> > Allowing for other numbers leads to mistakes. E.g. when using "-1",
> > is that false or true? And using 9999 for true doesn't make sense,
> > it is probably a mistake.
>

> I guess because I've mostly programmed in C/C++, I think of _**any**_

> nonzero value as truthy. That just feels idiomatic and natural to me.
> For instance, if I had a variable intended to hold a line number (or
> zero to signify undefined), I would think it natural to treat the line
> number variable as a boolean to test for definedness. But I realize
> this sort of thing is often frowned upon in modern, strongly typed
> languages...

C is quite old and very close to CPU instructions. It is easy to make
mistakes, e.g. checking if a pointer is NULL while you meant to check if
what it points to is zero:

char *ptr
...
if (ptr)

should have been "if (*ptr)" but doesn't give any warning.

> I didn't realize things would still work as before when the variable
> is used in a conditional. (A plugin user reported that the change was
> breaking something in a plugin I've contributed to, and I haven't
> actually tested with the latest version of Vim.)
>
> Would the "want_bool" flag be true if unary '!' is used to force
> interpretation of a variable as a boolean? E.g., will something like
> this continue to work as before?
> ```
> let valid_line_nr = !!line_nr
> if valid_line_nr
> ...
> endif

> ```

First of all, legacy Vim script and functions don't change. This only
applies to Vim9 script and :def functions.

You can indeed use "!" on any value, and it will use it as falsey/thruty
and result in true/false. Although the example should probably be:

let valid_line_nr = line_nr > 0

Since negative numbers are also invalid. And when "line_nr" happens to
be a string you will get an error, while "!line_nr" would test if the
string is empty.

--
If your company is not involved in something called "ISO 9000" you probably
have no idea what it is. If your company _is_ involved in ISO 9000 then you
definitely have no idea what it is.

(Scott Adams - The Dilbert principle)

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

—

[Brett Stahlman]

On Thu, Sep 24, 2020 at 4:40 AM Bram Moolenaar <notifi...@github.com>
wrote:

>
> Brett Stahlman wrote:
>
> > > Allowing for other numbers leads to mistakes. E.g. when using "-1",
> > > is that false or true? And using 9999 for true doesn't make sense,
> > > it is probably a mistake.
> >
> > I guess because I've mostly programmed in C/C++, I think of _**any**_
> > nonzero value as truthy. That just feels idiomatic and natural to me.
> > For instance, if I had a variable intended to hold a line number (or
> > zero to signify undefined), I would think it natural to treat the line
> > number variable as a boolean to test for definedness. But I realize
> > this sort of thing is often frowned upon in modern, strongly typed
> > languages...
>
> C is quite old and very close to CPU instructions. It is easy to make
> mistakes, e.g. checking if a pointer is NULL while you meant to check if
> what it points to is zero:
>
> char *ptr
> ...
> if (ptr)
>
> should have been "if (*ptr)" but doesn't give any warning.
>

I understand your point, though in my opinion, setting a pointer to NULL to
indicate it doesn't currently point to anything useful is a perfectly valid
idiom; in fact, the ability of a pointer to hold 0 is the reason pointers
are occasionally preferred over references in C++. But I don't deny that
problems can result when one is careless...

>
> > I didn't realize things would still work as before when the variable
> > is used in a conditional. (A plugin user reported that the change was
> > breaking something in a plugin I've contributed to, and I haven't
> > actually tested with the latest version of Vim.)
> >
> > Would the "want_bool" flag be true if unary '!' is used to force
> > interpretation of a variable as a boolean? E.g., will something like
> > this continue to work as before?
> > ```
> > let valid_line_nr = !!line_nr
> > if valid_line_nr
> > ...
> > endif
> > ```
>
> First of all, legacy Vim script and functions don't change. This only
> applies to Vim9 script and :def functions.
>

Ah. This is a relief. Now that I'm learning more about Vim9script, I'm
thinking this change shouldn't have caused any issues for the plugin, which
doesn't use the special "vim9script" directive.
I'm assuming that the experimental Vim9 fork will eventually be merged back
to mainline Vim, and that when that happens, legacy scripts will continue
to work normally because they don't contain the "vim9script" directive. Is
this a correct understanding?

Thanks,
Brett S.

> You can indeed use "!" on any value, and it will use it as falsey/thruty
> and result in true/false. Although the example should probably be:
>
> let valid_line_nr = line_nr > 0
>
> Since negative numbers are also invalid. And when "line_nr" happens to
> be a string you will get an error, while "!line_nr" would test if the
> string is empty.
>
> --
> If your company is not involved in something called "ISO 9000" you probably
> have no idea what it is. If your company _is_ involved in ISO 9000 then you
> definitely have no idea what it is.
> (Scott Adams - The Dilbert principle)
>
> /// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
> /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\ an exciting new programming language -- http://www.Zimbu.org ///
> \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
>
> —

> You are receiving this because you commented.

> Reply to this email directly, view it on GitHub

> <https://github.com/vim/vim/commit/d70840ed68296c1144d743e6335003c81c558c24#commitcomment-42683894>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAXOSQENP4C2WZNGXBS47B3SHMAXVANCNFSM4RXNAAXQ>
> .

[Yegappan Lakshmanan]

Hi,

The Vim9 support is already in the mainline Vim. It is not in a fork.

Regards,

Yegappan

[vim-dev ML]

[Brett Stahlman]

Ah. Ok. Guess I need to update to the latest so I can see why the plugin
user concluded the Vim 9 change was breaking a legacy plugin. Sorry for the
confusion...

Thanks,
Brett S.

> Regards,
> Yegappan
>
>
> >
> > Thanks,
> > Brett S.
> >
> >
> > > You can indeed use "!" on any value, and it will use it as
> falsey/thruty
> > > and result in true/false. Although the example should probably be:
> > >
> > > let valid_line_nr = line_nr > 0
> > >
> > > Since negative numbers are also invalid. And when "line_nr" happens to
> > > be a string you will get an error, while "!line_nr" would test if the
> > > string is empty.
> > >
> >
> >
>
> —

> You are receiving this because you commented.

> Reply to this email directly, view it on GitHub

> <https://github.com/vim/vim/commit/d70840ed68296c1144d743e6335003c81c558c24#commitcomment-42700054>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAXOSQELR6SWGAGLCWTYZ2DSHOEJJANCNFSM4RXNAAXQ>
> .
>

—
You are receiving this because you commented.

[Bram Moolenaar]

Brett Stahlman wrote:

> > > > Allowing for other numbers leads to mistakes. E.g. when using "-1",
> > > > is that false or true? And using 9999 for true doesn't make sense,
> > > > it is probably a mistake.
> > >
> > > I guess because I've mostly programmed in C/C++, I think of _**any**_
> > > nonzero value as truthy. That just feels idiomatic and natural to me.
> > > For instance, if I had a variable intended to hold a line number (or
> > > zero to signify undefined), I would think it natural to treat the line
> > > number variable as a boolean to test for definedness. But I realize
> > > this sort of thing is often frowned upon in modern, strongly typed
> > > languages...
> >
> > C is quite old and very close to CPU instructions. It is easy to make
> > mistakes, e.g. checking if a pointer is NULL while you meant to check if
> > what it points to is zero:
> >
> > char *ptr
> > ...
> > if (ptr)
> >
> > should have been "if (*ptr)" but doesn't give any warning.
> >
>
> I understand your point, though in my opinion, setting a pointer to NULL to
> indicate it doesn't currently point to anything useful is a perfectly valid
> idiom; in fact, the ability of a pointer to hold 0 is the reason pointers
> are occasionally preferred over references in C++. But I don't deny that
> problems can result when one is careless...

I just realized that what I mention actually would mean that the Vim9
behavior is wrong:

let list = []
if !list
echo 'list is empty'
endif

In legacy Vim script this gives an error, in Vim9 script it doesn't...
In my own defence, the legacy Vim script error is weird:
E745: Using a List as a Number

Opinions?

> > > I didn't realize things would still work as before when the variable
> > > is used in a conditional. (A plugin user reported that the change was
> > > breaking something in a plugin I've contributed to, and I haven't
> > > actually tested with the latest version of Vim.)
> > >
> > > Would the "want_bool" flag be true if unary '!' is used to force
> > > interpretation of a variable as a boolean? E.g., will something like
> > > this continue to work as before?
> > > ```
> > > let valid_line_nr = !!line_nr
> > > if valid_line_nr
> > > ...
> > > endif
> > > ```
> >
> > First of all, legacy Vim script and functions don't change. This only
> > applies to Vim9 script and :def functions.
> >
>
> Ah. This is a relief. Now that I'm learning more about Vim9script, I'm
> thinking this change shouldn't have caused any issues for the plugin, which
> doesn't use the special "vim9script" directive.
> I'm assuming that the experimental Vim9 fork will eventually be merged back
> to mainline Vim, and that when that happens, legacy scripts will continue
> to work normally because they don't contain the "vim9script" directive. Is
> this a correct understanding?

There is nothing to merge, the code is already there. So yes, legacy
Vim script won't change. It's like introducing Python 3 without
deprecating Python 2! :-)

--
The only way the average employee can speak to an executive is by taking a
second job as a golf caddie.

(Scott Adams - The Dilbert principle)

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

—

[Gabr-F]

Bram Moolenaar wrote:

I just realized that what I mention actually would mean that the Vim9
behavior is wrong:

let list = []
if !list
echo 'list is empty'
endif

In legacy Vim script this gives an error, in Vim9 script it doesn't...
In my own defence, the legacy Vim script error is weird:
E745: Using a List as a Number

Opinions?

Personally I prefer when a language steers clear of arbitrary,
unpredictable rules.

If it were a valid construct I could only know what if !list does
after consulting the language's documentation.

So, I think it would be better to return a type error (hopefully saying
"Using a List as a Boolean", though) and require using something like
if ! exists(list) and if ! empty(list).

[Nick Jensen]

I agree that this should be an error. In javascript an empty array is truthy, which is a constant source of errors and confusion.

var arr = [];
console.log(!!arr); // true
arr = null;
console.log(!!arr); // false

I think a type error here would lead to better and more readable code.

[Brett Stahlman]

I think what's confusing about the Javascript behavior is not the use of a collection in a boolean context per se, but that the "principle of least surprise" dictates that an empty collection of any kind should be treated as falsy, not truthy. Code like the following is actually quite intuitive:

if collection
        " Do something with collection...
endif

I suspect that most programmers - even those unfamiliar with Vim script - would have a pretty good idea of what that construct does. For a syntactic construct with multiple, equally obvious interpretations, generating an error might be appropriate, but I can think of only one obvious interpretation of a collection in boolean context...

Brett S.

[Brett Stahlman]

On Thu, Sep 24, 2020 at 4:40 PM Bram Moolenaar <notifi...@github.com>
wrote:

> I just realized that what I mention actually would mean that the Vim9
> behavior is wrong:
>
> let list = []
> if !list
> echo 'list is empty'
> endif
>
> In legacy Vim script this gives an error, in Vim9 script it doesn't...
> In my own defence, the legacy Vim script error is weird:
> E745: Using a List as a Number
>
> Opinions?
>

As I mentioned in another reply, I think there is only one obvious
interpretation of a collection in boolean context:
non-empty collection => True
empty collection => False

So IMO, generating an error for this case would add boilerplate without
enhancing readability or reducing errors...

Excellent! I wish Larry Wall had taken that approach with Perl 6: it might
have spared a lot of people in the Perl community a lot of angst...

Thanks,
Brett S.

>
> --
> The only way the average employee can speak to an executive is by taking a
> second job as a golf caddie.
> (Scott Adams - The Dilbert principle)
>
> /// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
> /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\ an exciting new programming language -- http://www.Zimbu.org ///
> \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
>
> —

> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub

> <https://github.com/vim/vim/commit/d70840ed68296c1144d743e6335003c81c558c24#commitcomment-42704051>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAXOSQCYKKJHFFPNMDJ6AATSHOVCDANCNFSM4RXNAAXQ>

[Bram Moolenaar]

Nick Jensen wrote:

> I agree that this should be an error. In javascript an empty array is
> truthy, which is a constant source of errors and confusion.
>

> ```javascript

> var arr = [];
> console.log(!!arr); // true
> arr = null;
> console.log(!!arr); // false

> ```

Yes, that's one of the things where Javascript/TypeScript is behaving
counter-intuitively. Let's avoid that.

> I think a type error here would lead to better and more readable code.

As mentioned before, I had been trying to follow TypeScript. But if we
are going to divert anyway, the question comes up if we should follow
TypeScript at all.

Assuming we require a condition to evaluate to a boolean, not a string,
list, etc., the question comes up what to do with "&&" and "||". In
TypeScript it is useful to do something like:

result = computed || 'empty'

If we go back to having "&&" and "||" resulting in true or false, then
we need something else for that. A trinary condition is a bit long:

result = computed ? computed : 'empty'

That can be shortened by introducing a new operator:

result = computed ?: 'empty'

Which is actually better, since here we don't expect "computed" to be a
boolean.

There is less use for this with "&&", "this && that" would always result
in "false" or "that", where "false" could be either the falsy "this" or
the falsy "that", the difference is hardly ever useful.

--
The budget process was invented by an alien race of sadistic beings who
resemble large cats.

[Bram Moolenaar]

> Bram Moolenaar wrote:
> > I just realized that what I mention actually would mean that the Vim9
> > behavior is wrong:
> >
> > let list = []
> > if !list
> > echo 'list is empty'
> > endif
> >
> > In legacy Vim script this gives an error, in Vim9 script it doesn't...
> > In my own defence, the legacy Vim script error is weird:
> > E745: Using a List as a Number
> >
> > Opinions?
>
>
> Personally I prefer when a language steers clear of arbitrary,
> unpredictable rules.
>
> If it were a valid construct I could only know what `if !list` does
> after consulting the language's documentation.
>
> So, I think it would be better to return a type error (hopefully saying

> "Using a List as a **Boolean**", though) and require using something like
> `if ! exists(list)` and `if ! empty(list)`.

Well, that is the main choice, either one of these:
- Require an explicit check for the list to be empty or not.
- Implicitly consider an empty list false and a non-empty list true.

Both are possible and have their advantages/disadvantages. So far I've
been mostly sticking with TypeScript, but we already agree that it
behaves unexpected in this situation (an empty list is considered true,
only a null or undefined list is false).

If we drop the idea of doing this like TypeScript, and we don't want to
make our own rules here, what other popular language could we follow?

--
Engineers will go without food and hygiene for days to solve a problem.
(Other times just because they forgot.)

[Andy Weidenbaum]

First of all, legacy Vim script and functions don't change. This only applies to Vim9 script and :def functions.

guns/vim-sexp has been broken since updating Vim past this patch:

Error detected while processing function sexp#leaf_flow:
line   34:
E1023: Using a Number as a Bool: 2

While I haven't bisected it to this patch, this patch does introduce E1023, so I presumed this patch is impacting legacy vim scripts.

ref: guns/vim-sexp#27

[Bram Moolenaar]

Andy Weidenbaum wrote:

> > First of all, legacy Vim script and functions don't change. This
> > only applies to Vim9 script and :def functions.
>
> guns/vim-sexp has been broken since updating Vim past this patch:
>
> ```
> Error detected while processing function sexp#leaf_flow:
> line 34:
> E1023: Using a Number as a Bool: 2
> ```
>
> While I haven't bisected it to this patch, this patch does introduce
> E1023, so I presumed this patch is impacting legacy vim scripts.
>

> ref: https://github.com/guns/vim-sexp/issues/27

Can you make a small reproducible example? If this is in legacy Vim
script it can most likely be fixed.

--
EXPERIENCE - experience is a wonderful thing. It enables you to
recognise a mistake when you make it again.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Brett Stahlman]

On Sat, Sep 26, 2020 at 5:49 AM Bram Moolenaar <notifi...@github.com>
wrote:

>

> Andy Weidenbaum wrote:
>
> > > First of all, legacy Vim script and functions don't change. This
> > > only applies to Vim9 script and :def functions.
> >
> > guns/vim-sexp has been broken since updating Vim past this patch:
> >
> > ```
> > Error detected while processing function sexp#leaf_flow:
> > line 34:
> > E1023: Using a Number as a Bool: 2
> > ```
> >
> > While I haven't bisected it to this patch, this patch does introduce
> > E1023, so I presumed this patch is impacting legacy vim scripts.
> >
> > ref: https://github.com/guns/vim-sexp/issues/27
>
> Can you make a small reproducible example? If this is in legacy Vim
> script it can most likely be fixed.
>

The error appears to be generated by searchpair() when a 'skip' expression
that evaluates to a number other than 0 or 1 is used: e.g.,

let pos = searchpair('a', 'b', 'c', '', 42)
E1023: Using a Number as a Bool: 42

Note that in the actual code, the skip expression is a call to a function
that intentionally returns different nonzero values to indicate where the
cursor is positioned relative to an s-expression list: e.g.,
0 => not on list at all
1 => on macro chars preceding opening bracket
2 => on list opening bracket
3 => on list closing bracket

IOW, there is 1 falsy value, but many truthy values, each of which conveys
potentially useful information beyond the fact that the cursor is on a
list. (Just pointing out that there are useful and not particularly
error-prone (IMO) idioms involving the use of numbers in boolean context...)

Thanks,
Brett S.

> --
> EXPERIENCE - experience is a wonderful thing. It enables you to
> recognise a mistake when you make it again.
>
> /// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
> /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\ an exciting new programming language -- http://www.Zimbu.org ///
> \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub

> <https://github.com/vim/vim/commit/d70840ed68296c1144d743e6335003c81c558c24#commitcomment-42743560>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAXOSQH7BJBHPEWYKG2I2PTSHW2JZANCNFSM4RXNAAXQ>
> .

[Bram Moolenaar]

I thought this was backwards compatible, but apparently it isn't.
I'll add a check for being in Vim9 code.

--
I learned the customs and mannerisms of engineers by observing them, much the
way Jane Goodall learned about the great apes, but without the hassle of
grooming.

(Scott Adams - The Dilbert principle)

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub, or unsubscribe.

[Brett Stahlman]

On Sat, Sep 26, 2020, 4:30 PM Bram Moolenaar <notifi...@github.com>
wrote:

>

Thanks!
Brett S.

> --
> I learned the customs and mannerisms of engineers by observing them, much
> the
> way Jane Goodall learned about the great apes, but without the hassle of
> grooming.
> (Scott Adams - The Dilbert principle)
>
> /// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
> /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\ an exciting new programming language -- http://www.Zimbu.org ///
> \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub

> <https://github.com/vim/vim/commit/d70840ed68296c1144d743e6335003c81c558c24#commitcomment-42751197>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAXOSQH5JYRN4YREZFD4XCDSHZFO5ANCNFSM4RXNAAXQ>
> .