Making rulestrings more consistent and readable

[speedydelete]

This is a tentative suggestion, I'm not trying to force this at all, and I'm welcome to feedback about it.

The current way rulestrings are written is very ad-hoc. We have:
- B3/S23
- B3/S23H
- /2/3
- /2/3H
- R2,C3,S4-5,B4
- R3,C2,S2,B3,N+
- R5,C2,S33-57,B34-45

The neighborhood type and state count are arguably more important than the B/S conditions, yet they are placed at the end of the rulestring, where users of left-to-right languages see them last. The information should flow in one direction in order of importance, like it does for e.g. URLs and many other identification systems. Furthermore, almost all research on these forums is done in English, and even the OT and INT rules have an inherent left-to-right information ordering (the 4 first INT transitions in left-to-right order are B0, B1c, B1e, and B2a, arguably the most important for determining a rule's behavior). so left-to-right seems like the way to go.

So, I suggest the following unified format:
- B3/S23 -> B3/S23
- B3/S23H -> NH/B3/S23
- /2/3 -> G3/B2/S
- /2/3H -> NH/G3/B2/S
- R2,C3,S4-5,B4 -> R2/G3/B4/S4-5
- R3,C2,S2,B3,N+ -> R3/N+/B3/S2
- R5,C2,S33-57,B34-45 -> R5/B34-45/S33-57
For neighborhoods above 9 cells, you need to use commas to separate them. "4-5" is not proper INT so it should be almost backwards compatible to allow ranges in INT rules too!

Of course, this is just a work-in-progress, please say any suggestions or criticisms of it you have!

I would be also interested in the historical rationales behind the current formats.

[dvgrn]

- /2/3 -> G3/B2/S
- /2/3H -> NH/G3/B2/S

Generations rule format being unlabeled S/B/G order is a particularly painful detail. Your suggested order and labeling is clearly theoretically superior.

That said -- if a new theoretically-superior rulestring format came into common use, it would mostly be a matter of Golly and LifeViewer having to be updated to support them, but there's a highly non-trivial amount of other parser code out there, written and maintained (or not) by lots of different people, that would trip painfully over the new format(s). As far as new formats are concerned, writers of parser code tend to have the mindset of "please can everyone just leave well enough alone?"

Until a format passes the practical test of actually being used by a lot of people, it's not too likely that Golly or LifeViewer will be updated to support the format.

So, unfortunately, in the absence of a time machine that can be used to go back and explain to people why they should be sensible and use a sane standard workable format right from the beginning, instead of inventing all those confusing and hard-to-read alternate rulestring formats in the first place, I regret to say that ...

well, Randall Munroe said it a long time ago.

[speedydelete]

That said -- if a new theoretically-superior rulestring format came into common use, it would mostly be a matter of Golly and LifeViewer having to be updated to support them, but there's a highly non-trivial amount of other parser code out there, written and maintained (or not) by lots of different people, that would trip painfully over the new format(s). As far as new formats are concerned, writers of parser code tend to have the mindset of "please can everyone just leave well enough alone?"

Until a format passes the practical test of actually being used by a lot of people, it's not too likely that Golly or LifeViewer will be updated to support the format.

Very good points. Note that the old formats should remain usable in Golly/LV/etc, just that they are normalized when used (e.g. when exporting patterns).

As for the standardization requirements, perhaps they could be first (after a consensus that this should happen is reached among the community, of course!) added to Golly/LV/etc but not with the normalization requirements, so /2/3 would become /2/3 but G3/B2/S would become G3/B2/S...

Edit: I don't mean to introduce the formats before they are widely used, that's probably not a good idea. Again, perhaps it's kind of hard to use the formats if they aren't supported...

Of course, realistically (as shown by the xkcd) it's unlikely that this even gets to the stage where it is considered by Golly/LV/etc, but in my opinion it is still good to try to get there.

As far as new formats are concerned, writers of parser code tend to have the mindset of "please can everyone just leave well enough alone?"

Funnily enough, I actually started thinking about this because I was about to write some parsing code... though I am probably the exception, not the rule.

[NNlk05]

The current format(s) work as is. Unless someone makes new software/updates current ones. And that isn't likely to happen if a majority of people uses the current ones.
Refer to xkcd #927: "Standards"

[speedydelete]

The current format(s) work as is. Unless someone makes new software/updates current ones. And that isn't likely to happen if a majority of people uses the current ones.
Refer to xkcd #927: "Standards"

Do they work as is though? I've seen several people be confused by the Generations and HROT formats, not to mention just the normal INT format (though that one is just jargon), and the inconsistencies can mess up even experienced Lifenthusiasts. Switching to a unified format also makes writing new parsers much easier.

Plus, a unified format allows for new kinds of rules to be expressed. It naturally allows for INT notations for other neighborhoods (see link for various examples). It can also express multi-neighborhood MAP, in the tentative format that would be something like "R2/NV/MAP...".

But, yes, your second point is quite correct. A unified format would have to get much farther along in usage, and that isn't likely to happen...

The edits were to fix typos.

[splitterrules]

I suggest that a new notation for MAP VN rules be created. At the moment, the notation consists of six unreadable characters, but due to the size of the rulespace it can be readable while being small.

[NNlk05]

I suggest that a new notation for MAP VN rules be created. At the moment, the notation consists of six unreadable characters, but due to the size of the rulespace it can be readable while being [sic] small.

See User:Apple_Bottom/Incubator/Swedish_notation.