Language Design: Force unsigned Bitwise Operations And Precedence of Operations

[A-Man]

Thank you very much for your time! I read your reply last night, but sadly didn't have time to reply to it.

The best solution I can think of is to introduce a new type, Bitfield that has bitwise operations defined for it, but not any arithmetic operations (so you cannot add them for example). It would be stored as a single 32-bit unsigned integer. Casting between floating points and integers is silly, and way more costly than necessary for no gain, so definitely do not do that.

I didn't think about the overhead of conversion I admit, and I really like the idea. I've been thinking how I'd represent the bitfield type, and how does a prefix 'b' sound?

200

is a number while

b200

is going to be a bitfield.

Enumerations are definitely also worth considering for the added type safety.

You mean implementing enumerations? I'm not sure how would that work with dynamic typing. Plus, there are some other concerns I haven't addressed with giving people freedom to create values like enumerations do. For example, It's more important that people should be able to use expressions in a markup language freely without having to enclose it with anything unnecessary.

Regarding other operators I like the way python does comparisons (

23<x<42

in python is equivalent to

23<x && x<42

in C++), so that would be nice.

Oh, will do!

I would also forbid different logical/bitwise operators operators to appear on the same level (so

a&b|c

is forbidden,

a && b || c

is also forbidden, but

a&b == 0 || c&d&e == 42

is fine).

I'm not sure about this, especially the logical && and ||. I've gotten used to || always being processed after &&, which comes handy like

a && b || c && d

is

(a && b) || (c && d)

, and is also kind of intuitive. As in real life, you don't hear confusing statements like "get apples or oranges and peaches or peers" very often, but "get milk and biscuits or cola && potato chips" is easy to interpret without much ambiguity. Perhaps it might different for people, but I'd still not forbid it; just maybe let it spew a warning message in a text file log (?). Bitwise AND and OR though, I feel OR should get the higher precedence. Since it's common for you to want to check whether your variable contains a multiple number of flags, like so:

value & flag1|flag2|flag3|flag4

. But maybe, for the sake of everyone's sanity, I can just give bitwise AND, OR and XOR the same precedence such that the first comes, first evaluated. I can spew a warning there too if they're on the same level if you insist it should.

Regarding text:
Please do NOT do that. The first one is not so bad, but the latter are particularly bad because they have different semantics to the first, despite having really similar syntax, but in general I just find that combining very different types leads to confusion in many cases and the alternative is not really that bad:

C++-Code: "text".repeat(4); // "texttexttexttext" "text".length() //4 "text"+to_string(42)

Or whatever similar syntax you prefer. Every single time I have seen some language try to infer programmer intent it has always gone wrong in one way or another.

lol, yes sir. I will use methods or anything similar for an alternative.

I really appreciate your insight! Thanks again.