ok @wren here's my graph-search DSL:

I feel pretty comfortable with nearly all of the operator-overloading I'd have to do:

A -> B


motif.A >> motif.B

But I don't have a good idea for how to render "A !> B". Thoughts?

Other syntax I support here:

And the language spec is here (extended backus-naur):

· · Web · 1 · 0 · 0


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:


@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

Sign in to participate in the conversation

extinct cow gang