Thanks again for the feedback, very much appreciated.
[deleting a long story]
Okay so, about the syntax... what LOC can bring to the table, being that Odin and Zig (and Jai?) are there already, is, I thought at some point, some different sort of appeal towards some HMN-preferred (allegedly?) imperative programming, close to the machine. For people having been introduced to programming with the likes of Python - I believe there are more of those than there are HMN members... ; and for total newcomers also. My target-sample for total newcomers being... my kids.
I've thought hard about introducing them to program in C, as Casey could do... but couldn't resolve to try and teach them programming with curly braces all over the place or trying to explain why the star in
const int* the_variable = hello <bracket> world <bracket>;
is where it is... so here you have the final pitch
for LOC: close to the machine, but being my language (scratching all kinds of itches, there), +control, +appeal in the form of a clearer, more inviting syntax.
So, I haven't programmed much Python myself, I'm of the C/C++[/Java/C#] brand by trade, and C++ by heart. With curlys. So, C++-frustration aside, it also feels weird to me atm, given that I haven't programmed that much in LOC yet, to forego curlys and semicolons. But I believe I can get used to it at some point. Even more so by the fact that programming the LOC compiler (in C++) with a few more macros than I would dare to write at work, made perfectly clear that I do not want to be hunting for a closing brace missing its opening brace in my files, ever again.
About the '::' and ':=' and ':'
This syntax is used by both Jai and Odin. To be fair, I kinda like their choice, and initially went for it. But I also remember Casey telling once, somewhere, that when he was young he was very puzzled by the math class, and the use of the '=' symbol, after having used that as the assignment operator all over the place. Well, he has a point, there. A very valid point. And given that I want to teach my kids, I did not want to expose them too much to an assignment-'equals' before they ever had a chance to see an equation at school. So, I chose the pascal ':=' for assignment
Now, because of that choice, ':' cannot represent the var declaration any more. And ':=' certainly cannot be used as the type-inferred var decl. And thus, 'as', it is... taking over the role of the previous ':' (so myvar as u8 = 5 is the LOC equivalent to jai's myvar : u8 = 5 and myvar as= 5 respectively for myvar := 5 in jai) It also feels a little weird for me atm, but I'm also getting used to it, as time goes. Constant decls, on the other hand, are restricted to the double '::' and cannot be using the separate-token form, like myconst : u8 : 5 (we'd use myconst :: u8(5) instead for same effect) I'll maybe change all of that at some point... (and I'm open to suggestions for an alternative declaration syntax, which would allow to keep ':=' specifically for assignment).
The point between ^ and the type to declare a pointer-type is indeed peculiar, but solves both a special representation for my parser, and the "issue" of ^ being a dead-key in some european keyboards: caret-dot is not "dead" any more. And using ^ for dereference comes at the end, as you noticed, so it's unlikely to produce î or ê by mistake either.
As for the why: it's for symmetry, and consistency with my_table as u8 for declaration, and my_table[i] for deref usage : you have my_ptr as ^.u8 for declaration, and my_ptr^ for deref usage. Maybe we're not so far apart, and it's what you're saying too, when mentionning your deref macros, but it always feels a little weird for me, years after, to have the deref star symbol come before the whole thing in C... I'm always tempted to leave parens around if there's any dot-descent in there... but I have the same problem with the addressof operator '&', mind you... which I still haven't adressed in LOC.
#"0" is currently my syntax for the '0' character (instead of the "0" string). I want to leave the single quote available for something else entirely. This may be subject to change.
%% and /% are currently for integer remainder and quotient, respectively. % and / are fmod and fdiv. This "may" become different once I iron-out the allowed implicit casts, but for now it makes very clear that 1/2 shall be 0.5
Regarding you comment:
u8.#trunc(uRemainingValue) feels a bit weird too. I'm assuming # is used for "compiler" directives so the fact that there is u8. in front makes it feel like it's a member of u8;
Yup, it feels like it's a member. This "was" by design, although I might reconsider if that weird feeling is shared by many others, or persists... Atm I'm okayish with it. A bare u8(something) has invocation-syntax, and would default-cast something to u8.
u8.somecastspec(something) would cast something to u8, according to a cast-spec which is not 'default'. Now, assuming the type could be a struct, I didn't want the possible cast specs to conflict with members, thus they're prefixed with # so that you cannot use them as your user-specified identifiers anyway (and they stand out in code as something peculiar you're doing there). As for '#' being compiler directives, well... it's not as if LOC had a C preprocessor, so it's more of a marker for something special, yeah. And preventing name-collisions in a more enforced manner than "user shall not use double underscore prefixes".
Many thanks again for your comments.