Confusing behavior with filenames starting with a digit

[ghost]

Janet symbols are represented as a sequence of alphanumeric characters not starting with a digit or a colon

---

Sorry if this not suitable for pre-0.1

($ ls 1.png)

parse error in <janetsh> around byte 12: symbol literal cannot start with a digit

($ ls :work)

Outputs content from the other folder named `work`, not `:work`

[andrewchambers]

I am aware of this, it is a fairly big annoyance, but expected considering how janet shell is a thin layer on top of janet.

That being said, it I can see some possibility for change:

I think ':work' could be expanded to ':work', that does seem less surprising. The reason it does not currently is because I was using :1.png as a shorthand instead of needing quotes. Thinking now, it seems less intuitive, so should probably be fixed.

As for numbers in symbols, it seems we can fix this by copying the the janet parser class into our own code and making some small changes. This parser would probably be only used for the interactive repl and not script mode to retain backwards compatibility with janet.

Otherwise we could convince @bakpakin to allow symbols to start with numbers in janet if they are unambiguously not numbers, but we shouldn't rely on exerting our will/preferences on janet, we are only users of janet. I currently consider this a largely pointless limitation, especially since the parser is aware enough that this is a symbol already.

Even with these issues fixed, floating point could also cause problems for us when the number is printed in a different format/precision than the user input, this may be even harder to fix.

I thought a bit about this problem and wondered if it was crazy for a new type of macro which accepts a source buffer and can output ANYTHING. I think it would be pretty cool.

For now we have to quote using " like cave (wo)men.

[andrewchambers]

@bakpakin

One other change that would make our lives easier would be if '~' could appear in symbols. That does break quasi quote of individual symbols, though that is a pretty rare thing to do, since the purpose of quasi quote is to be able to unquote, which in meaningless for a single symbol.

I can understand not wanting to do that change more though.

[andrewchambers]

Ok thinking more I have another idea, we can create string forms of the macros and side step any limitations.

($ "ls -la 1.png (+ 1 2 3) ")

It feels a bit gross, but may be the best way to solve these problems.

[bakpakin]

I think your key problem is reusing the Janet parser as is. In other projects where I need to embed janet values in an external syntax, I simply redefine the Janet parser as a peg. See https://github.com/bakpakin/mendoza/blob/master/mendoza/markup.janet#L37 for such a peg. With some modification, this could parse Janet forms and is easy to modify with any syntactic changes you would want.

[andrewchambers]

More thought is needed, but so far the best idea is a hybrid approach allowing the mixture of parsed strings, and janet symbols:

($ "ls (+ 1 2 3) | tac" | something  )

This still requires more thought though, as I can see issues with how to escape things you really want to be raw strings in an intuitive way, (maybe quote forms?).

[andrewchambers]

Right now I don't have the time budget to fix this, but maybe in the future.

[andrewchambers]

@ALSchwalm depending on how this is addressed, it also affects completions.

[andrewchambers]

I am starting to think "Confusing behavior" means a tutorial problem and not a technical one we can solve in a sensible way without forking janet (besides the keyword issue, which I made #212 for).

I am certainly not forking janet, so I won't be working on this. If someone comes up with a backwards compatible solution that works for script mode and interactive mode I can consider it.