ok @wren here's my graph-search DSL: https://github.com/aplbrain/dotmotif/
I feel pretty comfortable with nearly all of the operator-overloading I'd have to do:
```
A -> B
```
becomes
```python
motif.A >> motif.B
```
But I don't have a good idea for how to render "A !> B". Thoughts?
Other syntax I support here: https://github.com/aplbrain/dotmotif/wiki/Getting-Started
And the language spec is here (extended backus-naur):
https://github.com/aplbrain/dotmotif/wiki/Language-Spec
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`
(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`)
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 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
@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