Peter Marreck (Sep 13 2024 at 14:29): Peter Marreck (Sep 13 2024 at 14:29):From the Num docs: "In some languages shiftLeftBy is implemented as a binary operator <<."
I'd actually like those infix operators, if possible... or at least, they don't seem to be recognized in the REPL...
Brendan Hansknecht (Sep 13 2024 at 15:32):Yeah, they don't exist in roc currently
Peter Marreck (Sep 13 2024 at 15:37):I hope they do eventually just end up as infix sugar for Num.<bitwise operator name> (and & for bitwiseAnd etc.) just for the sake of POLS for people from other languages where these operators are pretty much universal... but it might make sense to only include them on an import, since not every project would need these and Roc likes to keep namespaces small... but there's probably no conception of "imported infix sugar" yet
Brendan Hansknecht (Sep 13 2024 at 15:38):I honestly don't remember why roc doesn't have these operators. I know it was discussed before, a long long while ago.
Brendan Hansknecht (Sep 13 2024 at 15:40):@Richard Feldman is there a specific reason roc doesn't have infix operations for shifting and bitwise manipulation?
Richard Feldman (Sep 13 2024 at 18:05):original thought was just that they wouldn't come up that often and we might want to use that syntax for something else
Richard Feldman (Sep 13 2024 at 18:05):I'm open to including them if we think they're common enough things to do in Roc
Sam Mohr (Sep 13 2024 at 18:51):If we move towards keywords over operators for the logical ops like and and or, we may lean away from adding more symbols. Slight lean, I think these are separate enough anyway
Brendan Hansknecht (Sep 13 2024 at 19:57):Yeah, I don't think they are really common enough to justify symbols. But symbols would definitely make certain classes of code much more readable.
Brendan Hansknecht (Sep 13 2024 at 19:58):They also definitely will be used if we push certain algorithm into roc like dealing with network protocols.
Notification Bot (Sep 14 2024 at 05:42):A message was moved from this topic to #ideas > symbols vs keywords by Brendan Hansknecht.
Shaiden Spreitzer (Sep 14 2024 at 08:00):Shouldn't it be possible to implement custom operators for some types (within reason)? Like multiply for matrices or bitwise ops for bitfields etc.? I mean these are some of the most basic things a cpu can do, the idea that they are "not common" is a bit silly tbh.
Roman (Sep 14 2024 at 08:02):will roc language make its way in zed editor?
Brendan Hansknecht (Sep 14 2024 at 15:18):Shaiden Spreitzer said:
Like multiply for matrices or bitwise ops for bitfields etc.?
Maybe, but custom operators or even overriding existing operators is not supported in roc today. I don't think custom operators will ever be supported (just given the mess it becomes in languages like Haskell). Overriding existing operators may someday be a feature, but not in the foreseeable future.
I mean these are some of the most basic things a cpu can do, the idea that they are "not common" is a bit silly tbh.
While bitwise operations are primitives for a CPU, that doesn't automatically make them common operations in code. Even looking at a lot of c++ codebases, while bitwise operations are definitely used, they often make up a very small percentage of the total operations. It heavily depends on the use case, but the code written today in roc does not use bitwise operations very often at all. Certainly much less often than many other functions that don't have symbols.
Peter Marreck (Sep 19 2024 at 01:59):Algorithms for things like hashing, encryption, implementation of Bignum, sorting, UUID, and a whole bunch of stuff we usually consider "stock" in the standard libraries of most languages commonly use bit manipulation. As a first project idea in "building something useful with this shiny new language that is one of the few functional languages to compile down to machine code" I considered implementing a basic Bignum (ambitious? Maybe), but lo and behold, there's plenty of bit manipulation there. Not only that, a feature of Elixir (my day job) that has become useful more often than you think is pattern-matching on bit patterns (real-world example: validating a UUIDv7). In short, it's definitely useful in use-cases where there's no other option.
Doesn't necessarily mean it needs infix sugar across the whole language. Which is why I was suggesting it might be an optional import of some kind. It would be neat if I could define (or override the default of) certain infix operators or sugar on a module basis...
Richard Feldman (Sep 19 2024 at 03:23):Peter Marreck said:
Doesn't necessarily mean it needs infix sugar across the whole language. Which is why I was suggesting it might be an optional import of some kind. It would be neat if I could define (or override the default of) certain infix operators or sugar on a module basis...
I think adding << and >> would be fine on the grounds that although they're only used in a narrow range of scenarios, those scenarios are somewhat common in libraries and the infix op makes them a lot easier to understand
Richard Feldman (Sep 19 2024 at 03:23):I think the bar for adding >> and << to builtins is pretty low, but the bar for adding custom infix operators is super high :big_smile:
Richard Feldman (Sep 19 2024 at 03:24):Elm used to have custom infix operators and removed them, and I think that decision was for the best in retrospect based on how they were used in practice
Richard Feldman (Sep 19 2024 at 03:25):we have talked about overloading existing operators (specifically to facilitate custom numeric structures in userspace), which I'm open to, but it's not really a priority right now
Brendan Hansknecht (Sep 19 2024 at 04:09):Would we also add |, &, and ^?
Peter Marreck (Oct 03 2024 at 20:07):here's a crazy idea, if overridable infix operators were removed from Elm (and I believe never added to Elixir, and now Roc) because of the opacity baggage they bring, what if we permit the definition of infix functions with full english names?
So in other words if overriding ^ in some context led to hard-to-understand code, perhaps an appendTo infix function that basically did the same thing might still be useful?
Brendan Hansknecht (Oct 03 2024 at 20:11):So that would be equalient to |> appendTo in current roc (though maybe with slightly different precedence rules)
data |> appendTo list
Anton (Oct 04 2024 at 09:17):I don't we should allow infix functions (without |>), because that would mean you can never be sure about the precedence at a glance, like is appendTo an argument to a function or an infix function.
Peter Marreck (Oct 08 2024 at 19:57):Aside to this, I had no idea Kotlin had infix functions already, this was an idea I came up with independently, but since I now know of a whole conversation complete with criticisms about its existence in that language, I (and anyone else) can just defer to that ;)
Brendan Hansknecht (Oct 09 2024 at 00:15):Kotlin had infix functions already
As in had at some point in the past and removed now?
Sam Mohr (Oct 09 2024 at 00:34):@Brendan Hansknecht https://kotlinlang.org/docs/functions.html#infix-notation
Sam Mohr (Oct 09 2024 at 00:34):They still have them
Sam Mohr (Oct 09 2024 at 00:35):I think it's an option in Kotlin because it's not ambiguous with respect to normal function application syntax
Sam Mohr (Oct 09 2024 at 00:35):But still, no need to dig that hole in Roc
Sam Mohr (Oct 09 2024 at 00:35):Because of |>
Last updated: Jul 06 2025 at 12:14 UTC