user poll: syntax and semantic of bitwise builtins

[Volth]

Hi

Bitwise builtins are going to be added to Nix to simplify operations
with IP addresses and netmsks, which are tricky to do having only four
arithmetic functions + - * / [1][2]

As those tickets might be unnoticed by most of the people and the
issue is to small to start an RFC, I would like to perform a broader
user poll with two questions:

A. Should "123>>64" evaluate to "64" (as in Java and Javascript) or
"0" (as in C and Perl) ?

B. Should there be only the prefix form ("builtins.__bitwiseAnd 123
456") or the infix form too ("123 & 456")

1. https://github.com/NixOS/nix/issues/1532
2. https://github.com/NixOS/nix/pull/2157

[Volth]

oops, must be


A. Should "123>>64" evaluate to "123" (as in Java and Javascript) or

"0" (as in C and Perl) ?

[zimbatm]

How about adding a few more built-in functions instead?

Changing the parser is going to have a long tail of things to fix, like all syntax highliters, HNix, ... And also make it more difficult to extend the language in the future.

I would rather start with some builtins to demonstrate the feature and add operators later if it becomes a very common thing to do.

--
You received this message because you are subscribed to the Google Groups "nix-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nix-devel+...@googlegroups.com.
To post to this group, send email to nix-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nix-devel/CAP6MKsuTuj-Rv9_ov9Wmf1SaQ2DnVVS_m_o979%3D0tKDLMZP-yQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Will Dietz]

Bitwise and, or, xor: sounds okay to me (&, |, ^).

Other operations such as bitwise not, ~, and shifts to some extent, require a notion of integer width that AFAIK is at most a minor part of the Nix language and possibly unspecified so far.

On shifts:

IMO Java-esque shift semantics are bizarre to the point of being beyond undesirable (honestly I'd much rather it be a runtime error), behavior when shifting into or out of sign bit needs consideration, as does providing ashr vs lshr...

I think I'd rather Nix grew bitfield types or something, vs bringing this sort of shenanigans to its integer types...

I recognize this is driven by use cases that would benefit, so I don't mean to discourage this direction entirely but would be sad to see Nix motivating me to implement some sort of "-fsanitize=integer" or "-fsanitize=undefined" :P.

To view this discussion on the web visit https://groups.google.com/d/msgid/nix-devel/CANEP-f4%3Dd0owcmqCtZNzvWKwN%3D-fAAS-mg%2B%3D_LK79FjYkF%2BnHA%40mail.gmail.com.

[an...@nix-devel.l.notmuch.email]

I pretty much share the opinion of zimbatm. Adding more operators might
not be desirable. Builtins on the other hand are a lot more subtile and
easier to "emulate", if there is a need to implement them in pure nix
for some reason (e.g. backporting things).

Adding specific types for those operations so bitwise operations are
more explicit would also be something I could imagine.


andi-