`and` and `or` keywords for binary operators · ideas

also, we could continue to parse the current ones (maybe just ignoring the edge case) and have the formatter quietly turn them into and and || for you

Richard Feldman (Jan 17 2025 at 03:23):

and have the compiler warn if they're used as binops

Joshua Warner (Jan 17 2025 at 03:23):

Yeah I was thinking exactly the same thing

Richard Feldman (Jan 17 2025 at 03:23):

because a lot of beginners will trip over that out of habit

Richard Feldman (Jan 17 2025 at 03:23):

(coming from other languages)

Anthony Bullard (Jan 17 2025 at 03:23):

{-# LANGUAGE BrokeYourShortCircuitingOperators #-}

Joshua Warner (Jan 17 2025 at 03:24):

Hey, nowhere did I suggest breaking short circuiting!

Anthony Bullard (Jan 17 2025 at 03:24):

I know, sorry, I'm on a tear with the breaking short circuiting jokes, and it's past my bed time

Joshua Warner (Jan 17 2025 at 03:24):

Haha np

Anthony Bullard (Jan 17 2025 at 03:25):

Also, I have to dig at Haskell every opportunity I get

Anthony Bullard (Jan 17 2025 at 03:25):

Because I'm not smart enough to write a White Paper

Sam Mohr (Jan 17 2025 at 03:28):

same

Anthony Bullard (Jan 17 2025 at 03:28):

Or read zero point style

Anthony Bullard (Jan 17 2025 at 03:29):

I'm just a Monoid that's NOT in the category of endofunctors

Richard Feldman (Jan 17 2025 at 03:29):

I haven't fact-checked this, but here's what perplexity.ai says:

Languages using "&&" and "||"

C
C++
Java
JavaScript
C#
PHP
Swift
Go
Kotlin
TypeScript
Rust

Languages using "and" and "or"

Python
Ruby
Lua

Languages supporting both "&&"/"||" and "and"/"or"

Perl
R

Languages with unique operators

MATLAB (uses "&" and "|" for element-wise operations, "&&" and "||" for short-circuit operations)
Visual Basic (.NET) (uses "And" and "Or" for bitwise operations, "AndAlso" and "OrElse" for short-circuit operations)
SQL (uses "AND" and "OR" keywords)
Haskell (uses "&&" and "||" for boolean operations, but also has "and" and "or" functions for lists)

Anthony Bullard (Jan 17 2025 at 03:29):

Also include PHP in the "and" and "or" category

Richard Feldman (Jan 17 2025 at 03:29):

it supports both?

Richard Feldman (Jan 17 2025 at 03:30):

oh this is interesting rationale: https://github.com/ziglang/zig/issues/272 (although we have ? for control flow, so we don't follow that convention anyway)

Anthony Bullard (Jan 17 2025 at 03:30):

CoffeeScript
Common Lisp
Emacs Lisp
Io
Logo
Lua
Modula-2
Perl
Raku
PHP
Pliant
Python
Ruby
Scheme
Smalltalk

Sam Mohr (Jan 17 2025 at 03:30):

We have been having some parsing troubles in the interaction of our new |args| body function syntax and our || or binary operator syntax. Namely, || is both a list of zero arguments and also the "or" operator. To avoid having to require indentation when we see binary operators at the start of a line, why don't we instead switch to and and or for binary operators?

Joshua Warner (Jan 17 2025 at 03:31):

Collecting arguments from other threads.

Pros:

Avoid ambiguity with || empty_arg_closures
Reasonably common (e.g. Python)

Cons:

Less common in c-like languages (only Zig that I'm aware of)

Possible mitigations:

Keep parsing && / || and always format them into and/or - and plan on keeping this around long term
For ||, require it to not be on the start of a line, or be very clearly indented (to keep avoiding ambiguity)

Notification Bot (Jan 17 2025 at 03:31):

67 messages were moved here from #ideas > zero-arg functions & sugar by Sam Mohr.

Anthony Bullard (Jan 17 2025 at 03:32):

Richard Feldman said:

oh this is interesting rationale: https://github.com/ziglang/zig/issues/272 (although we have ? for control flow, so we don't follow that convention anyway)

I was arguing for a Zig style keyword for this. I actually loved that style when I was on my Zig arc

Sam Mohr (Jan 17 2025 at 03:33):

The other contender here is not. Do we want to change !is_admin(user) to not is_admin(user)?

Richard Feldman (Jan 17 2025 at 03:33):

feels like that will create more parens

Sam Mohr (Jan 17 2025 at 03:33):

I'd say yes for consistency, as that one can be operator overloaded pretty easily

Sam Mohr (Jan 17 2025 at 03:33):

I'm not sure if it will

Richard Feldman (Jan 17 2025 at 03:34):

oh maybe not nm

Richard Feldman (Jan 17 2025 at 03:34):

:thinking: we could consider .not()

Sam Mohr (Jan 17 2025 at 03:34):

Yep

Richard Feldman (Jan 17 2025 at 03:35):

would we keep != at that point?

Joshua Warner (Jan 17 2025 at 03:35):

Python does that

Joshua Warner (Jan 17 2025 at 03:35):

So, not (hah!) that weird

Richard Feldman (Jan 17 2025 at 03:35):

it's kinda funny that right now you can have !foo!()

Sam Mohr (Jan 17 2025 at 03:35):

Actually, removing != means that you don't need to have == and != impls for custom types

Sam Mohr (Jan 17 2025 at 03:36):

just a single .equals() method

Richard Feldman (Jan 17 2025 at 03:36):

I don't think we want to remove !=

Sam Mohr (Jan 17 2025 at 03:37):

The problem is when we lose efficiency because of this, but that's pretty minor

Richard Feldman (Jan 17 2025 at 03:37):

either rename or keep as-is

Richard Feldman (Jan 17 2025 at 03:38):

I dunno, ! feels nicer to me than not

Richard Feldman (Jan 17 2025 at 03:39):

it's more concise, doesn't reserve a keyword, is easily understood

Richard Feldman (Jan 17 2025 at 03:39):

has symmetry with !=

Richard Feldman (Jan 17 2025 at 03:39):

I think we should keep that one as-is

Sam Mohr (Jan 17 2025 at 03:39):

A discussion on this from only 4 months ago: #ideas > `not` keyword instead of `!` prefix @ 💬

Sam Mohr (Jan 17 2025 at 03:39):

Same conclusion

Sam Mohr (Jan 17 2025 at 03:40):

It has symmetry of !condition and x != y

Richard Feldman (Jan 17 2025 at 03:40):

oh yeah I forgot about this point:

Richard Feldman said:

I don't have strong feelings about not vs ! but I do appreciate that if we're making ! mean "an effect is happening here" that it makes it even easier to scan a chunk of code for effects if that is the only thing that ! means

Richard Feldman (Jan 17 2025 at 03:40):

good point, Past Me

Sam Mohr (Jan 17 2025 at 03:40):

hmmm

Sam Mohr (Jan 17 2025 at 03:41):

We'd have to pick a != equivalent we'd even consider, then

Sam Mohr (Jan 17 2025 at 03:41):

Or of course, get rid of !=

Richard Feldman (Jan 17 2025 at 03:42):

Ayaz Hafiz said:

I always find not super annoying in Python
because != and = exist but not ! and sometimes i forget because in other languages it's available
keeping != seems like a good idea too. i mean even sql added != because it was more familiar than <>

Richard Feldman (Jan 17 2025 at 03:43):

a consistent theme in that thread is very strong support for != as the "not equals" operator

Richard Feldman (Jan 17 2025 at 03:43):

and if we have that, then we can't have "! only means effectful function"

Richard Feldman (Jan 17 2025 at 03:44):

at which point I'd agree with More Recent Past Me on this:

Richard Feldman said:

it's more concise, doesn't reserve a keyword, is easily understood
has symmetry with !=

Richard Feldman (Jan 17 2025 at 03:45):

although

Richard Feldman (Jan 17 2025 at 03:45):

I guess a counterargument is that != would never appear touching a letter (in practice)

Richard Feldman (Jan 17 2025 at 03:45):

so foo! would always stand out as a separate token from !=

Richard Feldman (Jan 17 2025 at 03:46):

plus they would be syntax-highlighted differently because one is part of a name and the other is an operator

Richard Feldman (Jan 17 2025 at 03:47):

so maybe it's fine if ! is only for effectful function names and !=

Richard Feldman (Jan 17 2025 at 03:47):

in terms of scannability

Richard Feldman (Jan 17 2025 at 03:47):

(although status quo feels fine there too, heh)

Joshua Warner (Jan 17 2025 at 03:48):

Is a not= b so terrible?

Joshua Warner (Jan 17 2025 at 03:49):

Actually I think I answered my own question

Joshua Warner (Jan 17 2025 at 03:49):

That does look terrible

Luke Boswell (Jan 17 2025 at 03:49):

I've been playing with different samples from various repos... and they all look fine to me. Here's an example.

is_hex : U8 -> Bool
is_hex = |b|
    (b >= '0' and b <= '9')
    or (b >= 'a' and b <= 'f')
    or (b >= 'A' and b <= 'F')

Luke Boswell (Jan 17 2025 at 03:50):

I second Sam's argument that this is more beginner friendly

Joshua Warner (Jan 17 2025 at 03:51):

We could always do the same thing with !foo and _parse_ it but format it as not foo

Luke Boswell (Jan 17 2025 at 03:52):

I don't love the idea of using not though...

Joshua Warner (Jan 17 2025 at 03:52):

Maybe I've just been doing too much python, but... "that's what python does" is a reasonably strong argument in my book

Joshua Warner (Jan 17 2025 at 03:53):

That said, IIRC that did get a bit of getting used to when I first learned python

Joshua Warner (Jan 17 2025 at 03:53):

Particularly not vs != was a bit confusing

Luke Boswell (Jan 17 2025 at 03:53):

expect not is_hex('g')
expect not is_hex('\\')
expect not is_hex('-')

Joshua Warner (Jan 17 2025 at 03:54):

Imagine this in the context of effectful functions

Joshua Warner (Jan 17 2025 at 03:55):

expect !foo!()

expect not foo!()

Joshua Warner (Jan 17 2025 at 03:55):

Honestly I think the not is a lot more readable in that situation

Joshua Warner (Jan 17 2025 at 03:55):

Too many !s going on

Richard Feldman (Jan 17 2025 at 03:55):

effectful functions that return booleans are pretty rare though

Luke Boswell (Jan 17 2025 at 03:55):

We would encourage Tags though for roc...

check_file! : Str => Result [Good, Bad] [IOError]
check_file! = |str|
    if str == "good" then
        Ok(Good)
    else if str == "bad" then
        Ok(Bad)
    else
        Err(IOError)

Richard Feldman (Jan 17 2025 at 03:56):

the only common one I can think of is !File.exists!(path) but actually I think that's kind of a counterexample, in that usually if you're doing something like "if it doesn't exist, then create it" you're leaving performance on the table compared to attempting to create it and then ignoring any "it already exists" errors

Richard Feldman (Jan 17 2025 at 03:57):

(2 syscalls vs 1)

Luke Boswell (Jan 17 2025 at 03:57):

expect is_hex('A') and not is_hex('g') or is_hex('0')

I think not is growing on me... but I want to keep!= and == is that rational?

Richard Feldman (Jan 17 2025 at 03:58):

it's what Python does

Joshua Warner (Jan 17 2025 at 03:58):

is_internet_connected!()

Richard Feldman (Jan 17 2025 at 03:58):

I think we should decouple the not discussion from the and and or discussion

Richard Feldman (Jan 17 2025 at 03:58):

and and or solve a problem with lambda syntax

Richard Feldman (Jan 17 2025 at 03:59):

not is stylistic only

Joshua Warner (Jan 17 2025 at 03:59):

If we switch to and and or, I'd argue we should at least _parse_ not and turn it into !

Joshua Warner (Jan 17 2025 at 03:59):

Those three often go together

Richard Feldman (Jan 17 2025 at 03:59):

that would make it effectively a reserved keyword

Joshua Warner (Jan 17 2025 at 03:59):

Yes

Joshua Warner (Jan 17 2025 at 03:59):

Well, mostly

Richard Feldman (Jan 17 2025 at 03:59):

haha

Joshua Warner (Jan 17 2025 at 04:00):

We can parse most constructs just fine, especially if we don't support WSA anymore

Richard Feldman (Jan 17 2025 at 04:00):

I don't think we should reserve a keyword and then not use it for anything semantically :big_smile:

Joshua Warner (Jan 17 2025 at 04:01):

In fact - in a non-WSA world, not doesn't have to be reserved at all in order to parse not foo

Joshua Warner (Jan 17 2025 at 04:01):

You could have a function called not() just fine, for example. You could also define that function without issue. Or have an arg with that name, etc.

Joshua Warner (Jan 17 2025 at 04:03):

I don't think we should reserve a keyword and then not use it for anything semantically

FWIW C++ does exactly this with and / or (and I think not?)

Joshua Warner (Jan 17 2025 at 04:04):

Most people use && / ||, but you can also do and / or and it means the same thing

Joshua Warner (Jan 17 2025 at 04:04):

Not that c++ is a shining example of a language

Richard Feldman (Jan 17 2025 at 04:07):

yeah fair point about the space having different meaning

Richard Feldman (Jan 17 2025 at 04:08):

at any rate, are there any concerns/objections about switching to and and or?

Richard Feldman (Jan 17 2025 at 04:09):

seems like the general sentiment so far has been neutral to positive

Richard Feldman (Jan 17 2025 at 04:09):

but that may just be because the alternative perspective hasn't been voiced in the thread yet :big_smile:

Joshua Warner (Jan 17 2025 at 04:11):

I think the main concern I heard was that you can't name things like that e.g. for a dsl

Joshua Warner (Jan 17 2025 at 04:11):

With some very slight caveats tho I think that can actually work out fine as a non-reserved keyword

Joshua Warner (Jan 17 2025 at 04:12):

For example:

and = |a, b| build_and_node(a, b)
and(1, 2)

Joshua Warner (Jan 17 2025 at 04:13):

In both of those cases, we just need a lookahead of 1 "token" (even tho the parser doesn't use those now!) to know that those can't possibly be operators

Joshua Warner (Jan 17 2025 at 04:13):

Actually no I take that back

Joshua Warner (Jan 17 2025 at 04:13):

That could be parsed as:

and = |a, b| build_and_node(a, b) and (1, 2)

Sam Mohr (Jan 17 2025 at 04:14):

That seems like it shouldn't parse that way, though I believe you that it would today

Sam Mohr (Jan 17 2025 at 04:15):

If the function body starts on the same line as the args, we shouldn't parse more statements

Sam Mohr (Jan 17 2025 at 04:15):

Unless they have at least 1 space of indent

Joshua Warner (Jan 17 2025 at 04:15):

Ahh true; that's not ambiguous in that particular case

Joshua Warner (Jan 17 2025 at 04:16):

a + b
and(1, 2)

... is ambiguous in that way tho

Joshua Warner (Jan 17 2025 at 04:16):

Or, more properly,

foo!()
and(1, 2)

Joshua Warner (Jan 17 2025 at 04:17):

We could keep the current rule where we're very particular about whitespace between the function and the parens

Joshua Warner (Jan 17 2025 at 04:18):

e.g. so if you actually wanted the and operator you'd have to write:

a + b
and (1, 2)

Joshua Warner (Jan 17 2025 at 04:18):

That feels fragile tho, particularly if that's the only place we need that constraint

Joshua Warner (Jan 17 2025 at 04:20):

I'd vote for making them reserved keywords

Joshua Warner (Jan 17 2025 at 04:20):

We can always relax that in the future

Sam Mohr (Jan 17 2025 at 04:21):

It works as a method, though

Joshua Warner (Jan 17 2025 at 04:21):

Only at the start of an expression

Joshua Warner (Jan 17 2025 at 04:22):

Otherwise it's almost-but-not-technically ambiguous

Joshua Warner (Jan 17 2025 at 04:22):

You could do (and(1, 2)) with zero ambiguity, or 1 + and(1, 2)

Sam Mohr (Jan 17 2025 at 04:26):

Oh, I meant with the dot in the front

Sam Mohr (Jan 17 2025 at 04:27):

Which is most of the usage for methods

Joshua Warner (Jan 17 2025 at 04:27):

Ah interesting

Joshua Warner (Jan 17 2025 at 04:28):

I was imagining a dsl for building up z3 expression

Sam Mohr (Jan 17 2025 at 04:28):

I'd expect left.and(right) in SD Roc

Joshua Warner (Jan 17 2025 at 04:28):

Ahh, true that works

Joshua Warner (Jan 17 2025 at 04:29):

I was imagining it as a function

Joshua Warner (Jan 17 2025 at 04:29):

It'd be weird if that was the one example of something you _had_ to call via SD

Sam Mohr (Jan 17 2025 at 04:29):

Which means we don't want it as a reserved keyword, unless methods get exempt from that keyword collision check

Joshua Warner (Jan 17 2025 at 04:29):

Err, I would still vote to make it reserved

Sam Mohr (Jan 17 2025 at 04:30):

Pretty sure that's how we'll check for SD types

Joshua Warner (Jan 17 2025 at 04:30):

My dsl can be andz(1, 2) instead and it's not terrible

Joshua Warner (Jan 17 2025 at 04:31):

What I _would_ love for such a DSL is operator overloading :P

Kilian Vounckx (Jan 17 2025 at 07:39):

Just some trivia
c++ allows both '&&' and '||', as well as 'and' and 'or'

Even c apparently has the <iso646.h> header which defines macros to turn the keywords into operators. It was used historically for users with keyboards that didn't have the symbols

Kilian Vounckx (Jan 17 2025 at 07:39):

0a6976e7-25e9-49af-b5d6-cf0a1ce7aae3.png

Kilian Vounckx (Jan 17 2025 at 07:40):

Here is a full list in the c header

Anthony Bullard (Jan 17 2025 at 10:43):

I’ll just say this. People who put a space between the function and the arguments in PNC have questionable motives. I’m coming at you GNU

Norbert Hajagos (Jan 17 2025 at 15:49):

Anthony Bullard said:

I’ll just say this. People who put a space between the function and the arguments in PNC have questionable motives. I’m coming at you GNU

Yeah, I don't trust them too :big_smile:

I like the and and or keywords. They seem beginner friendly. Always perceived them friendly, as in kind and welcoming (syntax is so much about vibes).
I'm unsure aboutnot. It seems wrong to see two keywords after eachother like thing and not other_thing. Different syntax highlighting would help, but there's no such problem with !. There is just something clear about ! coming right before the operand, without a space. A solution to this particular problem would be thing and other_thing.not(), which brings the opearnd (in this case argument) together with the not operator. If that's the style that will be mainstream, that will look even more weird to outsiders than combining and, or and !. It also doesn't help that thing.not() reads backwards compared to how you would think about it in English.

jan kili (Jan 17 2025 at 19:13):

Richard Feldman said:

it's kinda funny that right now you can have !foo!()

Coming soon: ¿por_qué!?

jan kili (Jan 17 2025 at 19:16):

I have a selfish two thumbs up (👍 and 👍) for replacing symbolic operators with ~~reserved keywords~~ words in general, and especially these two. (since today I'm mostly writing scripts that prioritize readability to a non-technical audience)

Sam Mohr (Jan 17 2025 at 21:34):

Bool.and and Bool.or mean that we can't make these operators reserved keywords, I think

Sam Mohr (Jan 17 2025 at 21:36):

I did something funky for Result.try where we parse the word "try" as its own AST node, and if it doesn't desugar to a LowLevelTry, then we convert it back to the word "try"

Sam Mohr (Jan 17 2025 at 21:36):

We could try do the same thing here?

Richard Feldman (Jan 17 2025 at 22:13):

Sam Mohr said:

Bool.and and Bool.or mean that we can't make these operators reserved keywords, I think

we can just remove those

Richard Feldman (Jan 17 2025 at 22:24):

I think now that we do short-circuiting, it's probably a bit confusing to have them (for use in pipelines) because they don't short-circuit

Sam Mohr (Jan 17 2025 at 22:26):

Oh, that's fair

Sam Mohr (Jan 17 2025 at 22:26):

I was trying to do it in spite of what you said in case I could make it work somehow

Sam Mohr (Jan 17 2025 at 22:26):

But if they don't short circuit, that's a problem

Richard Feldman (Jan 17 2025 at 22:39):

yeah, the footgun aspect makes me think whatever convenience they offer isn't worth it

Sky Rose (Jan 18 2025 at 04:30):

If we lose Bool.and, we lose the ability to use .and() in static dispatch. (Which is probably fine, but worth saying we're okay with it.)

Sky Rose (Jan 18 2025 at 04:32):

(deleted)

Sam Mohr (Jan 18 2025 at 04:34):

If methods are allowed to have keyword names, then that restriction could go away

Sam Mohr (Jan 18 2025 at 04:35):

Which still is a restriction since it means you can't call the method like a normal function

Sam Mohr (Jan 18 2025 at 04:35):

But that seems minor to me

Sky Rose (Jan 18 2025 at 04:51):

Oh I wonder if you could also refer to the function if it was qualified Bool.and. Like as long as it's got a dot before it you know it's the function not the keyword

Brendan Hansknecht (Jan 18 2025 at 04:53):

I feel like that is something not worth worrying about yet. I think direct use of Bool.and is exceptionally rare and it is a pretty minimal cost to have to type |a,b| a and b

Brendan Hansknecht (Jan 18 2025 at 04:54):

Probably less common in roc cause using Bool is so rare when tags are so easy and promoted in general.

Richard Feldman (Jan 18 2025 at 05:00):

Sky Rose said:

If we lose Bool.and, we lose the ability to use .and() in static dispatch. (Which is probably fine, but worth saying we're okay with it.)

I think this is good though - if it's a function (that takes two non-functions for arguments) then it's not short-circuiting and is error-prone

Richard Feldman (Jan 18 2025 at 05:00):

I think we're better off not having it

Sam Mohr (Jan 18 2025 at 05:01):

Bool.and in particular we shouldn't keep, yes. But would it be bad to have .and() available for DSLs?

Sam Mohr (Jan 18 2025 at 05:02):

Yes, we don't need to worry about this yet

Richard Feldman (Jan 18 2025 at 05:02):

yeah I think we can think about that later

Richard Feldman (Jan 18 2025 at 05:02):

it's obviously not blocking any DSLs since you can just add a letter as a workaround :big_smile:

shua (Jan 22 2025 at 08:38):

for some other point, I know lean has some equivalent functions between functions that return Prop and functions that return bool. The latter usually get a b prefix, so eg eq for Prop and beq for bool. We could do the same with Bool.band and Bool.bor. Not exactly aesthetic.

Alternatively, And and Or are traits in rust, so overloading the trait overloads the meaning of a && b, and I've used that and BitAnd in some rust dsls to get nice and-y or-y syntax.

Last updated: Jun 16 2026 at 16:19 UTC