Patch try to accept (try body ([] catch-body))

[iacore]

Fixes #1603

Also makes (try 1 ([] (error "hi"))) valid.

[pepe]

Perhaps I don't understand it entirely, but what is the purpose of (try 1 ([] (error "hi")))? Frankly, I do not see any value in the change.

[iacore]

I use it to change the error message. For example, (try (arr 0) ([] (error "array empty"))

[sogaiu]

I may be missing some of what's going on in this discussion (^^; -- but below are some related thoughts.

For try, IIUC, usually a name is chosen for the error portion of the catch if we're going to use it:

(try
  (error "hey")
  ([e]
    (print "hi:" e)))

If we don't want to have to choose a name (because we aren't going to use the information) we can do:

(try
  (error "hey")
  ([_]
    (print "hi")))

but:

(try
  (error "hey")
  ([]
    (print "hi")))

seems ok to me too.

---

There's another part of the PR which is to improve the error message, which IIUC is what #1603 was originally mostly(?) about:

The error message is weird. (got 101)

For the reported case, I did find the error message to be puzzling.

[pepe]

For the usage, I see _ totally fine, even better to be honest.

For the error, that is true, but then there are more places, where to guard it. I mean more macros. Do we want to have these guards everywhere? But I am ok with that, not the issue I had on my mind. Sorry for not being clear.

Not my call anyway, just my opinion.

[sogaiu]

For the usage, I see _ totally fine, even better to be honest.

Yeah, I am ok with using _ as well.

Just curious why you think using _ is better. It's not obvious to me and I'd like to see if I'm missing something :)

For the error, that is true, but then there are more places, where to guard it. I mean more macros. Do we want to have these guards everywhere?

It's a good question.

On a somewhat related note, I wasn't so keen on this initially, but in that case it turned out later that I benefited from it repeatedly (still do occasionally!), so I am not so clear on when it's better 😅

May be for the def / defn case, it's fairly likely to happen whereas it's not as clear in this case?

[pepe]

It is better for me, cause it signals to me that something is omitted. TBH I love the [&] the most.

For def and defn, I agree very much. And also, I understand the need for this guard. It is just that I am not sure about asserts in macros. I guess we can build a debate about linting in this context?

[sogaiu]

Thanks for sharing.

It seems like the proposed change gives behavior that's similar to using [&] -- though may be I misunderstood?

(defn f [& args] :smile)

(f)
# =>
:smile: 

(f 1)
# =>
:smile

(f 1 2)
# =>
:smile

May be you were saying that there is something positive about the proposed behavior?

---

Taking a closer look at try...the way it is currently, it requires the catch part to have at least one element:

[e]

I presume we all know that it can have two though:

[e fib]

I assume that one reason it is this way is because one doesn't always want to use the associated fiber. If that's the main reasoning, it seems reasonable to me to also make e optional. That seems consistent in a way. I guess that would be like [&opt e fib] - close to [&], but would error with 3 or more arguments?.

Alternatively, one could have always required two elements in the tuple, i.e. [e fib]. That also feels like it has a similar type of consistency to me. If one didn't want either argument, one could express the catch part of the try as [_ _]...though using _ more than once seems somewhat uncommon.

With the way things are currently, [e] doesn't explicitly signal that the associated fiber is being omitted. So may be similar to [e &opt fib]? In terms of having to remember things, I think this is the one that I'd be most likely to have trouble with 😅

In terms of not breaking things with existing code, allowing [] seems ok to me (though I do wonder how common that use case is likely to be -- perhaps when quickly writing code it's more common?).

---

I'm even less sure about assert use in macros 😅 I went through boot.janet though and I do see a few macros that use assert (defdyn and may be ffi/defbind-alias?). Not many though!

Regarding linting, do you think it would be practical for the checking to be done via flycheck? I guess not everyone uses that -- though I am saved by it quite frequently.

---

On a related note, try lacks examples at the website docs. Having some examples there possibly could help for future occasions, but I guess one would have to think to look to benefit.

[iacore]

On a related note, try lacks examples at the website docs. Having some examples there possibly could help for future occasions, but I guess one would have to think to look to benefit.

I would like to see example in (doc try). Reading the usage in natural language ... need to wrap my head around that.

Regarding linting, do you think it would be practical for the checking to be done via flycheck? I guess not everyone uses that -- though I am saved by it quite frequently.

flycheck for EMACS? Not sure how to use that.

[pepe]

https://janet-lang.org/docs/linting.html for the reference.

[sogaiu]

I would like to see example in (doc try).

This has been touched on elsewhere, but I believe it's pretty much a policy to not include examples in the docstrings.

However, we've been adding examples to this page. (To get an idea of what this can look like, please see this portion for all.)

We can add some examples for try there.

On a side note, earlier this year a number of us made an effort to increase the coverage. There is still a lot that could be added for sure.

Reading the usage in natural language ... need to wrap my head around that.

FWIW, there is some prose on the website for try in this section.

Hmm, it's interesting that the prose there seems to be describing what might be considered the behavior being proposed in this PR:

if any error is raised, optionally bind the error and the raising fiber in its second clause.

[sogaiu]

flycheck for EMACS? Not sure how to use that.

Ah sorry. flycheck happens to also be the name of the feature in janet available via -k for using the built-in linting that pepe linked to.

For editor support, I've had some success getting it to work with Emacs and Neovim [1], and I think pepe had something for kakoune. May be other people have had success with other editors too.

---

[1] For Emacs, there is at least flycheck-janet and for Neovim using nvim-lint with the following in init.vim seems to work here:

lua << EOF
-- manually triggering -> :lua require("lint").try_lint()
require('lint').linters_by_ft = {
  janet = {'janet'},
}
EOF

lua << EOF
-- TextChangedI might be worth trying at some point
vim.api.nvim_create_autocmd({ "BufRead", "BufWritePost", "InsertLeave" }, {
  callback = function()
    require("lint").try_lint()
  end,
})
EOF

[sogaiu]

I've made a PR with some initial examples here.

Below is how they can end up looking in a web browser on the aforementioned page.

[iacore]

Nice! Are we going to accept this patch or not?

[sogaiu]

Ultimately, I think it's up to @bakpakin.

[bakpakin]

LGTM, esp. the addition of the improved error message.