Ok, I've basically finalized all the (more than very trivial) language issues ... I am just going to repost:
Some final notes before I begin in
(May or June?). THESE ARE DECIDED (tentatively):
The new numeric datatypes are byte, sbyte, int, and uint.
String literals can take on different forms:
::: "null terminated string"
::: b"byte-prefixed string"
::: i"int-prefixed string"
::: r"raw string"
Numeric literals are of type "int" by default. Type-casts can be used to be explicit: (byte)5;
Hexadecimal and Binary literals are prefixes with 0x and 0b, respectively, and default to type "byte" or "uint" types according to the number of digits used (so as to reflect a literal bit representation).
Dereferencing is now on the right-side:
::: *[]byte pa; (*pa)[idx];
::: []*byte ap; *(ap[idx]); // or just *ap[idx]
Constant (immutable) variables are defined with "const"
in addition to the datatype.
Constant expressions (pasted in like macros) are defined with "const" alone.
It is illegal to mix "const" or "volatile" with the ":=" operator.
There are standard-, BASIC-, and iterator-style for-loops:
::: for(init; condition; update)
::: for(var: start, end, inc) (inc is optional)
::: for(var: array); for(var: someYieldyCofunc)
The inferred type of an array literal works as follows:
::: []T{...} = A static array of the given values
::: &[]T{...} = Pointer to the given static array
::: new [n]T = Pointer to a new (uninitialized) array allocation
::: new []T{...} = Pointer to a new array allocation (values copied from static array)
Arrays with the (first) dimension omitted ([]T or [,n]T) are pointers.
Arrays of the form [ , ,...] are rectangular (stored in one static allocation).
Arrays of the form [][][]... are jagged (the "inner" arrays are stored as pointers).
Arr[3..6] is a shorthand for the tuple expression (Arr[3], Arr[4], Arr[5]).
Tuples will remain "auto-unpacked", and no tuple-variables allowed.
Method receivers ("this") are ALWAYS (intrinsic) pointers.
Methods may be defined within structs, just as in Java/C# (compact/familiar).
There will be an "
[email protected]" syntax for embedding variables within array literals.
Addressing goes on the LHS and applies to the whole RHS (e.g. &a[n] is &(a[n])).
Entities may not be defined within each other (e.g. no structs within structs, etc.).
Expressions cannot contain statements (declarations, assignments, calls, var++/var--).
Anonymous functions may may not refer to (non- static/const) external local variables.
All code is precomputed as much as possible (without unrolling loops or recursive calls).
The $ operator
Requires something to be interpreted,
including loops and recursive calls.
Bridge methods will be inserted for multiple "inheritance" of anonymous fields, as needed.
Control-flow constructs will indeed require parenthesis (avoids parsing conflicts with literals).
No "static" members of anything (but static local vars and static initialization blocks are allowed).
Entites Have Global Accessibility If They Are Capitalized, and namespace accessibility otherwise.
Look-Up-Tables (rather than Jump Tables) will be used with switches and if-else chains as possible.
Methods can only be defined for "identifier" types (structs, primitives, etc., but not funcs, arrays, etc.).
Namespaces may be nested ("Outer.Inner" syntax), and there will be a "using Namespace" mechanism.
Self-Modifying code will be used with cofuncs and switch-variables (Will consider an option to disable it).
Explicit variable addresses can be nominal (@"address") or refer to another variable (@x or @arr[n].foo).
No exception-handling or "try-catch" mechanism (use multiple return values or create an "Exit()" instead).
Type-casts will be represented traditionally (e.g. "(byte)(a+b)").
"Extra" Parenthesis are not allowed within datatypes ("func(...)" requires them, but []*T are *[]T are unambiguous).
Function pointers without any return values may point to functions with return values (e.g. func(byte) pointing to func(byte):byte).
Values will be passed/returned in registers such that any two functions with the same pattern of arguments will use the same registers for them.
Default arguments (and struct members) must come last, and will be embedded in functions so they can be pointed-to as their reduced versions.
An anonymous (nameless) struct/interface/cofunc/func within a namespace will take on the name of the namespace (e.g. "List myList" rather than "ListNameSpace.ListStruct myList"). This also gives namespace values ("List.staticValue") the feel of Java/C#'s static class members.
