I think this is a great idea but IMO it should be more robust. I can see a couple of points where the command would fail:

• Quoted cell path members: "foo.'filename.txt'"
• Cell paths with integers: "foo.0.b"

I keep thinking we shouldn't add new logic handling these cases because that would be just duplicating the logic that's already in the parser. What I would try:

1. Create a new working set and use the lexer to correctly split the input string, same as here.
2. Use parse_cell_path() on the stream of tokens to get the cell path expression <-- maybe not the best idea
3. Create Value::CellPath from the expression.

Stuff like that is generally not safe, but I think this should OK because the CellPath and PathMember structs do not reference anything new added to the newly created working set (which will be thrown away). They only point at spans which are already present in the old working set. It would be a problem if we added subexpressions to cell paths, like foo.(let x = 'bar'; $x).

I'm going to merge this because it is an improvement over the current state but the above points should eventually be addressed.

Thanks for the PR, @Kangaxx-0. I reverted this for now because I'm working on some cell path improvements and the duplicated parser logic in into cellpath was causing trouble.

We'd welcome another PR to add this back with the improvements that @kubouch suggested (but if you're going to do that, maybe wait a little bit to avoid conflicts; my cell path changes will hopefully be done in the next couple days).

Thanks for the PR, @Kangaxx-0. I reverted this for now because I'm working on some cell path improvements and the duplicated parser logic in into cellpath was causing trouble.

We'd welcome another PR to add this back with the improvements that @kubouch suggested (but if you're going to do that, maybe wait a little bit to avoid conflicts; my cell path changes will hopefully be done in the next couple days).

I get the basic idea that comment is asking, however, I don't feel confident to reparse input during eval. In general, is it ok to call lex during command running, which is in evaluation stage?

Thanks for the PR, @Kangaxx-0. I reverted this for now because I'm working on some cell path improvements and the duplicated parser logic in into cellpath was causing trouble.
We'd welcome another PR to add this back with the improvements that @kubouch suggested (but if you're going to do that, maybe wait a little bit to avoid conflicts; my cell path changes will hopefully be done in the next couple days).

I get the basic idea that comment is asking, however, I don't feel confident to reparse input during eval. In general, is it ok to call lex during command running, which is in evaluation stage?

Using lex should be totally fine because it does not alter a state of anything. Maybe calling parse_cell_path() would be too sensitive, because you could get into a string interpolation which then could have sub-expressions which can modify the working set. So calling parse_cell_path() directly might not be the best idea, but using the lexer, you could at least split the cell path members correctly, instead of splitting the string manually by .. Then, following the logic found in parse_cell_path(), iterate through the lexer output and convert them to either integers or strings. This should be totally safe, you'd just be looking up spans from the engine state.

Using lex should be totally fine because it does not alter a state of anything. Maybe calling parse_cell_path()

I tried this and it was too difficult to get it to work. JT also didn't think we should do it as it comes too close to eval.