Back to the semantics of those operators. I don't think we have any problem of understanding them in the context of digits. All of these are pretty clear:

- Code: Select all
`(12) : 1 AND 2`

(1&2) : 1 AND 2

(1,2) : 1 AND 2 (split and ordered in a split and ordered group of cells)

(1|2) : 1 OR 2

However, the semantics of the same operators applied to a group of cells is not so clear, especially without any attached digits:

- Code: Select all
`r1c12 : ?`

r1c1&2 : r1c1 AND r1c2

r1c1|2 : r1c1 OR r1c2

r1c1,2 : ?

The AND and OR operators are relatively straight-forward, at least with the previously suggested semantics, but the other two are not. What exactly does the comma mean here? Does it imply splitting and ordering or not? What exactly does the default case r1c12 mean? In the digit context we could always replace (12) with (1&2), but what operator is implied in r1c12?

The seemingly obvious r1c1&2 doesn't work as a synonym for r1c12 if we maintain that (1)r1c1&r1c2 should mean 1r1c1 & 1r1c2 (which is a contradiction). The other option r1c1|2 does work in this case, since (1)r1c12 -> 1r1c1|1r1c2. However, that interpretation runs into problems if we have more digits:

(12)r1c1245 <-/-> (12)r1c12|45 <-/-> (12)r1c1|2|4|5

The first option means that both 1 AND 2 are found somewhere within those four cells (but obviously not in the same cell), e.g. 1r1c5 AND 2r1c1 is a valid combo. On the other hand, with my suggested semantics the second option is only valid with (12)r1c12 OR (12)r1c45 (in other words, both digits must be found in one or the other cell group -- or both but that's not possible in this case). The last option is not valid at all, because it represents four ORed single-cell groups, and (12) being two ANDed digits can't fit into a single cell.

So, if both & and | are out of the game, what would work? The only operator left is the comma, so it must be it. But what exactly does it mean in this context? To maintain any kind of consistency, I think it should imply splitting and ordering just like with the digits -- and it definitely does when used in combination with a comma in the digits. That's a bit of a problem because r1c12 does not imply any ordering, so r1c1,2 is not really a synonym for it. This is:

r1c12 <-> (r1c1,2 | r1c2,1)

That's in line with the digit context:

However, unlike the digit context where (12) <-> (1&2), there actually isn't any single operator that could be used within r1c12 to get the exact same semantics. The comma is pretty close and works in most practical cases, but it's not a synonym because it's not commutative: r1c1,2 is not the same as r1c2,1. What I would like to have is a fully commutative operator for cell groups, similar to & with the candidates, for when splitting and ordering is not wanted. My suggestion is the dot '.' :

r1c12 <-> r1c1.2 <-> r1c2.1 <-> (r1c1,2 | r1c2,1)

Now you're thinking that it doesn't make any sense, because why would we ever write r1c1.2 when we can write r1c12. You're right, we never would. However, the real need is for nodes with cells that don't see each other. Currently there's no way to write them with the same exact semantics of a seamless group like r1c12 (i.e. an unordered, unsplit group of cells). The only option to write them is with the comma r1c1,r9c9 but it's not exactly the same.

While the comma syntax almost always works in practice, it's not semantically accurate because it implies a split and ordered group of cells whether we want one or not. It can also cause actual problems when we do want a split and ordered group of cells (i.e. one or more commas are used with the attached digits) but not with that exact splitting point.

With the suggested dot syntax we wouldn't have such problems, because it wouldn't imply any ordering or splitting:

r1c12.r9c89 <-> r9c89.r1c12 <-> r1c1.r1c2.r9c8.r9c9 <-> r9c8.r1c2.r9c9.r1c1 <-> ...

The dot could also be used in other contexts as a more readable replacement for '&' (with the exact same semantics, unlike the comma I've been using for that purpose). Thus we'd have these four operator options (and one default) for both digits and cells:

Digits:

- (12) : <-> (21) <-> (1.2) <-> (1&2)
- (1.2) : <-> (2.1) <-> (12)
- (1,2) : <-/-> (2,1) ; -> (12)
- (1&2) : <-> (2&1) <-> (1.2) <-> (12) <-> ((1,2) | (2,1))
- (1|2) : <-> (2|1)

(Of those, only a,c,e are really needed in practice, but b,d are there for symmetry and completeness.)

Cells:

- r1c12 : <-> r1c21 <-> r1c1.2 <-> {r1c1 r1c2} : unsplit, unordered set of cells
- r1c1.2 : <-> r1c2.1 <-> r1c1.r1c2 <-> r1c2.r1c1 <-> r1c12
- r1c1,2 : <-/-> r1c2,1 ; <-> (r1c1,r1c2) : split, ordered tuple of cells
- r1c1&2 : <-> r1c2&1 <-> (r1c1 & r1c2)
- r1c1|2 : <-> r1c2|1 <-> (r1c1 | r1c2)

All five of these options have their uses.

--

So, what do you guys think of that? I know Steve must really hate the idea of adding yet another symbol

Sorry! I'm not really happy about it either, but I think it would make logical sense because there's an actual gap to fill. So, just a warning: I'll probably be testing the dot idea for a while to see how it works in practice.