Add compact arrays (#299) and pretty inline separators

[juntyr]

This PR includes the implementation for compact arrays from #299 (stale and quite tricky to rebase), and a fix for #290 to make the pretty RON prettier. Specifically, this means that:

• pretty tuples and arrays will now use a separator string after , when multiline is disabled
• pretty structs and maps will now use a separator string after : and ,
• this separator string is a single space by default

• I've included my change in CHANGELOG.md

[torkleyy]

Is it useful in practice to turn compact arrays completely on or off? It seems to me I'd want arrays with few and short elements compact, but as soon as the elements are non-primitive I'd probably want them all in their own line.
However, handling all the cases seems pretty hard as well...

[juntyr]

Is it useful in practice to turn compact arrays completely on or off? It seems to me I'd want arrays with few and short elements compact, but as soon as the elements are non-primitive I'd probably want them all in their own line. However, handling all the cases seems pretty hard as well...

I think the same question came up in the original PR. I think the best we could do is check the optionally sequence length against some threshold for finer control. While doing things based on type info would be awesome, I have no idea how this could be done in serde.

[torkleyy]

I don't think we can do that ahead of time. Also, I don't think we should try to cover all the possible formatting of RON. A full-blown formatter inside of the serialization code just makes is it unreadable and bloated - and I don't think other serialization libraries offer as much configuration as we have right now.

[torkleyy]

So my proposal:

1. Decide what's useful enough to have inside of RON
2. More involved formatting should be implemented in an external formatter

[juntyr]

So my proposal:
1. Decide what's useful enough to have inside of RON
2. More involved formatting should be implemented in an external formatter

That makes sense ... I assume this formatter would perform some light parsing of RON and take in a subset of the options PrettyConfig handles right now and transform the String?

[torkleyy]

So my proposal:

1. Decide what's useful enough to have inside of RON
2. More involved formatting should be implemented in an external formatter

That makes sense ... I assume this formatter would perform some light parsing of RON and take in a subset of the options PrettyConfig handles right now and transform the String?

Do you mean a superset? And yes, it will have to do its own parsing because

• we need look-ahead to determine whether we want to format in expanded or compact form
• parsing into something like Value and then formatting that would discard the comments

[juntyr]

So my proposal:

1. Decide what's useful enough to have inside of RON
2. More involved formatting should be implemented in an external formatter

That makes sense ... I assume this formatter would perform some light parsing of RON and take in a subset of the options PrettyConfig handles right now and transform the String?

Do you mean a superset?

Maybe a superset of a subset? I think the options struct_names, decimal_floats, and extensions would all remain as they can actually impact the RON besides some nicer whitespace usage.

And yes, it will have to do its own parsing because

* we need look-ahead to determine whether we want to format in expanded or compact form

* parsing into something like `Value` and then formatting that would discard the comments

What if this new Value also was a Serializer so that if you want pretty RON you could go into it directly without serializing to a String and then parsing the the String again for formatting?

[torkleyy]

Maybe a superset of a subset? I think the options struct_names, decimal_floats, and extensions would all remain as they can actually impact the RON besides some nicer whitespace usage.

Ah, yes, that makes sense!

What if this new Value also was a Serializer so that if you want pretty RON you could go into it directly without serializing to a String and then parsing the the String again for formatting?

Yes, certainly, I think it should be. I've even started such an attempt here: https://github.com/ron-rs/ron-reboot
So it's not a new Value type but really an AST that you can deserialize and serialize. ron-reboot works as it is, but some problems remain (which is also why I didn't get the word out):

• I don't really like the name. I don't think it should replace this ron repository but rather extend it
• The performance isn't acceptable. I knew it was gonna be slower due to intermediate representations, but it seems way too slow to me - I suspect a bug where it scans the whole input or something like that

[juntyr]

Yes, certainly, I think it should be. I've even started such an attempt here: https://github.com/ron-rs/ron-reboot So it's not a new Value type but really an AST that you can deserialize and serialize. ron-reboot works as it is, but some problems remain (which is also why I didn't get the word out):

* I don't really like the name. I don't think it should replace this `ron` repository but rather extend it

* The performance isn't acceptable. I knew it was gonna be slower due to intermediate representations, but it seems way too slow to me - I suspect a bug where it scans the whole input or something like that

That looks really cool!

[juntyr]

So what's the plan now? Should this PR get merged and at some point the options move to your formatter?

[torkleyy]

Yes, I think we should merge this but not accept any further configuration in the future, because I fear with every option the code becomes harder to maintain.
I'm hoping we can make such a formatter in the future but obviously it will require some work... Maybe I can figure out what's causing the performance problems some time next year and then continue from there and implement a basic ronfmt.

[juntyr]

Yes, I think we should merge this but not accept any further configuration in the future, because I fear with every option the code becomes harder to maintain. I'm hoping we can make such a formatter in the future but obviously it will require some work... Maybe I can figure out what's causing the performance problems some time next year and then continue from there and implement a basic ronfmt.

Ok, that's sounds like a good plan!