first [bad] idea that comes to mind is to implement `__invert__` on `Motif`, so `A !> B` becomes `~(A>>B)`. `~` has higher precedence than `>>` however, so the parens are required (and the same holds essentially regardless which operator you use, /unless/ you use `^` (but that doesn't look a whole lot like your dsl syntax))
if you want a single operator, i'd go with `/` or `%`, but neither look anything like what the DSL uses, and also, that doesn't work for the rest of `relation_type`
actually, scratch that: this requires that `Motif.__rshift__` returns something specific to the particular relation being defined, so `__invert__` knows what to invert - i think that's necessary in order to allow self-contradictory-but-syntactically-valid motifs like:
```
A>>B
~(A>>B)
```
@wren ooh sorry bb I was just thinking about a DSL spec, I haven't started yet! I like this, I don't love having to put parens around the expression but maybe it's not so bad, since it makes it pretty obvious that it's not a regular edge??
Maybe I'll try it and see how it feels — I do really like the idea of having errors in python-world instead of in parser-world
@wren but I would love to disallow this sort of collision — it shouldn't be permitted to write that motif without a compile error
@wren readability feels like a loser here, even though it's probably way [computationally]-cheaper to do the former than the latter
@j6m8
(this requires that `Motif.__rshift__` returns a `Motif` - is your implementation of the in-python operator overloading on a different branch that i can take a look at? unless i'm missing something, it doesn't appear to be implemented on `Motif` on `master`)