Thoughts on changing the shortcode syntax to disambiguate strings vs encoded vars?

[oddfacade]

As far as I can tell, the short code parser doesn't necessarily read the same thing it writes. For example, you can't ever have the string "0.0" because it'll be turned into a float. The basic problem is that we're relying on var_to_str for anything that's not a string, but and writing strings out verbatim (var_to_str would quote them. With our current logic you'd end up with e.g. `param=""hello world!""). It's admittedly not a huge deal in most common use cases, but it is rather unintuitive and needlessly complicates the parsing logic. On the other hand, I do understand why it's been done this way. Double quoting the strings is rather unergonomic, and it breaks the wordpress-style shortcode metaphor. I think we have a few alternative options though. Hoping to gather some opinions before I start hacking on an implementation.

Options:

1. Don't quote anything that's not a string. Naively, this seems like the easiest option, but I haven't really worked through the implications of the shortcode syntax. We'd want to escape = characters like we're currently doing, but we'd also have to do something about spaces. It might overcomplicate the parser regex. That being said, I think we might be able to get away with the naive approach if we limit the shortcode syntax to just the primitive data types, i.e. no TYPE_OBJECT. This shouldn't be a problem because it's what we're currently doing, but it would limit our options going forward.
2. Use different quotes for strings vs. other variants. Perhaps " vs ' or even `. This is definitely going to be confusing for the user, but it does make the implementation extremely simple.
3. Go with the first option, but use ` backticks (or any other quote character besides " or ') for the difficult cases (arrays, dictionaries, objects, etc.). I think this is probably the best compromise between user-friendliness, correctness, and simplicity/ease of maintenance. The downside is just that it's a bit less straightforward than the other two options.

The tradeoff for all of these is of course that you're going to be breaking the established syntax, and also moving away from the "standard" shortcode syntax.

Thoughts?

[Jowan-Spooner]

Hey @oddfacade, this is an interesting problem and some good suggestions, so thank you for this discussion first of all.
I have to say I really like the current approach from a UI and UX perspective. I actually think that using different separators or none would make the shortcode events less readable.

Thus I would like to first investigate methods of making dialogic cleverer at guessing the right type. As far as I can tell there is no parameters that have an ambiguous type. In fact all the underlying parameter variables should be statically typed and only allow one type anyways. So we should find a way of making sure if you are providing a String parameter it always gets to be a string no matter the content.

I'm not sure if this will fix the problem you are having tho. Maybeyyou can give some example situations where the current system was failing you?