Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x~ cannot be set to $nil #1248

Closed
gergelyk opened this issue Feb 23, 2021 · 5 comments
Closed

x~ cannot be set to $nil #1248

gergelyk opened this issue Feb 23, 2021 · 5 comments
Labels

Comments

@gergelyk
Copy link

@gergelyk gergelyk commented Feb 23, 2021

Since initial value of x~ is $nil, I would assume that $nil can be assigned to this variable any time.

[~]─> var x~
[~]─> put $x~
▶ $nil
[~]─> set x~ = $nil
Exception: wrong type: need nil, got nil
[tty 3], line 1: set x~ = $nil
[~]─>
@krader1961
Copy link
Contributor

@krader1961 krader1961 commented Feb 23, 2021

The confusing error message is a known issue, see #744. While it is true it is initalized to $nil when you declare the var without giving it a value you can't actually use it:

> var x~
> x
Exception: bad value: command must be callable or string containing slash, but is nil
[tty 55], line 1: x

A var name ending in a tilde is a function (or command if you prefer) and must be a lambda. You also can't assign a string to it:

> x~ = echo
Exception: wrong type: need nil, got string
[tty 56], line 1: x~ = echo

@xiaq xiaq added the bug label Feb 23, 2021
@xiaq
Copy link
Member

@xiaq xiaq commented Feb 23, 2021

@gergelyk Thanks, this is an interesting edge case. Maybe the initial value for $x~ should be changed to $nop~...

@gergelyk
Copy link
Author

@gergelyk gergelyk commented Feb 24, 2021

@krader1961, even though x~ set to $nil is not callable, it is still usable. E.g. I can imagine:

var callback~
# some code here which may set `callback~`
# some code here which may clear `callback~`
if (is $callback~ $nil) { echo "Nothing to do!" } else { $callback~ }

@krader1961
Copy link
Contributor

@krader1961 krader1961 commented Feb 24, 2021

@gergelyk, That's an interesting use case. I'm inclined to agree with @xiaq's proposal that the initial value be changed to $nop~ rather than special-case $nil. If you need to distinguish between code that might assign$nop~ and an uninitialized state you can always use a unique sentinel value:

> var none~ = { }
> var callback~ = $none~
# some code here which may set `callback~`
# some code here which may clear `callback~`
if (is $callback~ $none~) { echo "Nothing to do!" } else { $callback~ }

@gergelyk
Copy link
Author

@gergelyk gergelyk commented Feb 24, 2021

Yup, I agree. Proposal of @xiaq sounds reasonable.

krader1961 added a commit to krader1961/elvish that referenced this issue Mar 29, 2021
You cannot assign $nil to a lambda var so that should not be the initial
value of `var x~`. Instead, assign $builtin:nop~.

Fixes elves#1248
krader1961 added a commit to krader1961/elvish that referenced this issue Mar 29, 2021
You cannot assign $nil to a command var so that should not be the initial
value of `var x~`. Instead, assign $builtin:nop~.

Fixes elves#1248
@xiaq xiaq closed this in #1274 May 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

3 participants