Open StefanKarpinski opened 7 years ago
Yes, it makes sense.
I have an example where defining a negative operator as something not identical to !(operator(a,b)).
I use the unicode symbols ≺
and ⊀
(precedes, does not precede) with a directed interval type:
the .lo field may be larger than the .hi field, There is a topologically sound way of ordering these intervals where "not preceding" is distinct from the negation of precedes (which is ≽
, "succeeds or coincides").
We'd want to still be able to use ≉
as a function, so ≉
could actually parse as !(≈)
. It's a bit odd for something that looks like an identifier to parse as a call expression, but I'm not sure what the harm would be.
Might be simpler and more flexible to just define fallbacks for all the negated operators by default.
sounds like agreement (flexible simplicity with everywhere backstopping coverage)
Many operators (esp the nice looking ones with semantic relevance) are interposed to feel operational and pulled forward to feel functional. Julia is well-grounded and this means we are ok with this sort of multiperspecitve [secure in the knowlege that ^yall^ keep keeping it good, working smoothly]
https://github.com/JuliaLang/julia/pull/20261/commits/3ff5554e524593f9c04350037213b6b68eb2afbb made me wonder if it would make sense to simpy parse and lower operators like
a ≉ b
and such as!(a ≈ b)
. That way the user gets the negation of an operator for free if they define the positive and we don't need a slew of definitions like this. Of course, we could provide them by default and allow the user to override them but it's hard to imagine situations where defining a negative operator as something else would be a good idea.