Language Design: Force unsigned Bitwise Operations And Precedence of Operations

[A-Man]

Not sure.

b200

could also be a variable. Maybe a postfix although I would say enumerations would still be the better solution.

Actually, variables have a '$' prefix, or '@' for "system variables" (those which the engine will be changing, like the position of the player..etc). 'b' as a post-fix is what I'm going with it seems, as 'b' as a prefix usually denotes base 2 in other languages.

Simple. Don't implement dynamic typing. Like inferring programmer intent it is something I have never seen actually work in practice.
If you don't want people to write variable types implement type inference (

auto my_var = my_func();

in C++11).

What about Python, or Javascript (this uses 'var', but yeah, still dynamic)? They seem to have gotten that with no problems at all. I still really want to avoid a keyword for that. It's supposed to be a simple scripting language anyway, and I really care about its simplicity.

I'm not entirely sure what you meant here. You are making a scripting language, not a markup language, right?

It's a scripting language, but there is the equally important markup language. The markup part is like LF2 .dat files', except that the tags can use expressions. Think of it as using HTML with Javascript, except for this, the script will be something users can use to do more hardcore stuff. Possibly as an option to write AI too. You can have a look here for an example.
(the "$l." prefix refers to local variables inside the script, "$g." for global variables shared between all objects, "$p." for permanent variables which last beyond a game session (save data/settings/..etc) or simply '$' for variables local to the object only, including all the scripts inside/imported).

Quote (Click to View)

I did not even know the precedence of any of these operators, and I will surely forget it again, because I always use parenthesis around them anyway. You might have an easy time remembering their precedence, but code is much more important to be readable, and the vast majority of people don't, in fact to such a degree that Clang and GCC have implemented warnings for this. Again the alternative (adding parentheses is the code) only costs two extra characters, but it is guaranteed to be unambiguous to anyone reading it.
The same thing goes with bitwise operations the price is two extra characters, for clear unambiguity which I consider a small price to pay.

Fair points. I had grown tired from parenthesis jumbles before I learnt to break down long conditions into smaller parts.

I would also say that a lot of people would expect

|

and

&

to have the same precedence as

||

and

&&

. Also consider that it is much easier to go from a stricter syntax to a less strict syntax than vice versa since you break less code (in this case you would break nothing if you were to switch later).

[quote]
Giving them the same precedence also seems bad as I cannot think of any practical situations where that is preferred.

Because it's intuitive I think? I mean before we learnt about Exponents-Division/Multiplication-Addition/Subtraction (mistakenly taught to younger students as the "BODMAS rule"), I'd do everything in order; 5 - 5 * 3 equals to 0, and hell to all those teachers who argued! But yes, the point is, I believe people not familiar with stuff like bitwise operators will expect them to run in order. Those who have some experience in programming will just parenthesisize their way through. I'd consider.

While I personally think, and I'm sure you agree, that the premature syntax errors when extensive pay off with saving you time you'd spend fixing more troublesome semantic errors, I also think that overdoing it by rubbing lots of error messages on people's face puts them off. No language I've used has forbade that before, so I'd rather not as well. Though it seems a warning message will be necessary.

on a side note: I always laugh when I see you've added one other statement to your signature, as they're often directly calling to me. I've asked before why one wouldn't use NULL, and you gave me some valid reasons, but why not rand? Is it because RAND_MAX differs across compilers and stuff? What if I redefine it to what I want, or just cycle it around the range I want with %?

Thanks!