I think it should bind tighter than |> and looser than just about everything else.

not a >>>> !a
not a === b >>>> !(a === b)
not a = b >>>> !(a = b)
not a or b >>>> !(a || b)
not a or not b >>>> !(a || !b)  *
list.map not& >>>> list.map($ => !$)

data
  |> not&
---
($=>!$)(data)

* marks the one that I think may be dubious.

I think I figured out why I find this confusing. Currently:

• and and && have the same precedence
• or and || have the same precedence

...so it feels a little weird for not and ! to have different precedence.

But I think the fix is to change the precedence of and and or, to make them low as well! I just recalled that Perl does this. Having two levels of precedence lets you do neat things like this:

x || y and z || w >>>> (x || y) && (z || w)

I notice that Perl goes a little far: x = y or z parses as (x = y) or z. Maybe we don't want to go that far, but I think making and/or lower precedence than &&/|| would make me much happier about lowering not's precedence. (I think you want = to be added to your list with |> of lower precedence.)

I'd argue that not should be slightly higher precedence than and/or. Hence, if you stick to the same "type" of operator, you get intuitive (to me) relation between not/and/or:

!a || !b >>>> (!a) || (!b)
not a or not b >>>> (!a) || (!b)
not a || not b >>>> !(a || (!b))

What do you think? We'd need to turn this off for coffeeCompat.

I think that having different precedence for word and symbol operators in fine/good. I also agree that it would be best to keep the precedence the same within groups (!, &&, ||) and (not, and, or).

But having and /or and &&/|| be exactly equivalent is nice too.

Interesting to think about... we might want to let this one stew for a while.

Indeed, having and & or logical operators in but leaving not out is inconsistent.
Also Python folks would be confused if they couldn't find not while having and & or available.

Extending the subject further, I'd love other CoffeeScript keywords to officially return to Civet.
Like isnt, on, off, yes and no. ^_^

And to please Pythonists even more, elif as a shorthand for else if. 🐍

Like isnt, on, off, yes and no. ^_^

is not is already available in base Civet, and the others are all available if you set "civet coffeeCompat" (or more specifically "civet coffeeIsnt" and "civet coffeeBooleans").

elif is an interesting idea... By default or hidden behind a compiler flag?

Yea, that was my 1st Civet letdown that we'd need those "civet" flag thingies. 😿
What I'm hoping for is the official comeback of those CoffeeScript keywords to Civet as default. 🔑
We could make those keywords as opt-out flags instead of the current opt-in. 🙏

I'm trying to be very judicious about adding to the number of reserved words. Each additional reserved word prevents existing code from moving to Civet without issue.

@GoToLoop Hopefully config files will mitigate your issue once #103 gets completed. I myself have my preference on which flags I want on and which I want off, and I suspect everyone's preference will differ slightly.

Each additional reserved word prevents existing code from moving to Civet without issue.

• Indeed keywords such as yes, isnt, off prevent them to be used as labels.
• But I've never seen them as variable names anywhere in my whole life!
• For such rare edge-cases when a file needs to use any of them as regular labels, an opt-out flag would turn them off.
• In my defense to have them as actual Civet keywords is, as I understand, this language provides lots of shorthands already.
• So why not keeping those already existing CoffeeScript keywords as Civet keywords too, given they had never been an issue on CoffeeScript AFAIK.

FWIW, I believe on/off/yes/no come from YAML originally. They might make sense if we add more YAML features to make most YAML a subset of Civet.

I don't see why one would prefer isnt (which looks like a misspelling) over is not... but to each their own, of course.

isnt as shorthand for is not is similar to elif in place of else if. :D

Back to not/and/or vs. !/&&/|| precedence, some more prior art (beyond Perl) is that LiveScript gives such low precedence to and/or/xor that they close implicit calls:

even 0 and 3   →   even(0) && 3
even 0 &&  3   →   even(0 && 3)

It looks like Ruby also agrees on not/and/or being lower precedence than !/&&/||. It even puts not/and/or below assignment and x? null checking.

CoffeeScript seems to be the odd one out in making them aliases (at the lexer level) so identical precedence.

At this point I'd lean toward not/and/or being lower precedence than !/&&/|| (we'll have to decide exactly where), but coffee-precedence (or a better name?) / coffee-compat restores the CoffeeScript precedence.

The one downside is that this complicates the grammar... Related question: what precedence do custom operators have? Once there are two possible answers for binary operators, it's less clear... 😦

• Indeed keywords such as yes, isnt, off prevent them to be used as labels.
• But I've never seen them as variable names anywhere in my whole life!

In fact off is a pretty common variable name, sometimes short for offset. GitHub search reveals ~53,000 instances. on has over 42,000 occurrences. isnt is indeed rare at 190 instances, though it's apparently the name of an NPM package so it's not a crazy variable name.

P.S. not, and, and or are surprisingly common too, at 24,700, 11,000, and 14,900 occurrences. Sadly this code will be harder to port.

The lack of not is getting pretty surprising; coffeeNot is now the first Civet flag I reach for (and sometimes the only). So I'm going to try to implement the above two-different-precedences plan (word operators lower precedence than symbols, unless you specify coffeeCompat). Let me know if you think we should instead stick to CoffeeScript's flat precedence as the only option.

P.S. not, and, and or are surprisingly common too,

Well, for sure those happen in languages that don't have them as reserved keywords, right?

Civet is closely related to CoffeeScript, Python, Ruby.

Any programmer writing code for a Python-related language would already know they can't use those labels.

Idem for CoffeeScript. Once the compiler warns a programmer they can't use a reserved keyword as a label, such as off or yes, they'll just rename the variable.

Any programmer writing code for a Python-related language would already know they can't use those labels.

Right, so and/or/not are not that surprising as keywords. on/off/yes/no are, unless you come specifically from CoffeeScript (or YAML). I think we should just agree to disagree on this, as we already have coffeeBooleans to satisfy those who want them.

elif could probably be a similar flag extension, although I note only 99 occurrences throughout GitHub, and we could make it a soft keyword (activating only after an if block), so maybe it's worth adding to core. @GoToLoop Do you want to open a separate issue for it, so this thread can get back to not?

Is this closed by #557 ?

Yes, unless we want to continue discussing lower-precedence and/or/not. But I guess we have #548 to track that. I'm also not super convinced separate precedence is that important...