I've decided to make a few changes in syntax, perhaps implementing a more english friendly variant as well. So below is all the variants (they will match completely in the formation or IR). Both IR and the ByteCode variants will not change whatsoever.

Current Syntax Simplified

This syntax aims to just simplify the current code like syntax.

Changes

• Removed the ';' before each line (it can easily be done through newline and a boolean so why really track it) furthermore you can still use ; to place multiple on same line and fits more inline with code.
  • All current code will NOT break, you can still use ';' before a statement.
• Furthermore I've removed the ability to use '(', ')', '.', '[', ']', '<', '>'... in ';' statements and replaced it with ->, I'm not completely sold on this but I do like the removal of them since they were a massive reason of slowdown in implementations and just lead to confusion (and with the addition of constructors / arrays it adds even more confusion).
• I'm thinking about replacing the = in the '@' statements with : and perhaps replacing the @ with something else.
• Comments: Same as 'normal' one

Example

// This is a comment
// Construct a new System.Color
@ Test        = System.Color ...
              .RGB                   = 255, 64, 128 // Implicit 'array'

@ TheSame     = System.Color ...
              .RGB->Normalised       = 1, 0.25, 0.5, // You can have trailing commas

@ AgainSame   = System.Color ...
              .RGB->Hex              = 0xFF4080; .Name = "Other" // You can put them on same line with ';'

/* Multi Line Comment Blocks are great */
@ Copy        = System.Color ...
              .RGB                   = Test.R, Test.G, 125 // Reference other objects
              .Name                  = "Copy"

AgainSame.Name = "OtherName" // You can reference variables and set at any point

Shorter Syntax

This syntax aims to simulate JSON kind of expressionism allowing similar structures. This has a few advantages since it does look generally simpler and doesn't require alignment to the same degree that causes nightmares with the first one.

Changes

• '@' Statements :
  • '@' is removed basically every statement is now a '@' statement (outside of statements in {...})
  • = is now : (It makes it look better when using { ... })
  • ... is replaced with { ... } (you place the ; instead of ...) furthermore there is no singular statement like AgainSame.Name = "OtherName" you have to do AgainSame { Name = "OtherName" } (still a single line but slightly more verbose, though could put over multiple lines if wanted).
• ';' Statements :
  • Same as simple syntax, with the only difference being they have to lie within the '@' { ... } statements, no need to use ; if using newlines and if on same line just using ; before each new statement is fine (doing it this way acts as a primer and is easier to parse, though adding a superfluous one is fine).
• Comments: Same as 'normal' one

Example

// This is a comment
/* This
    Is a 
    Multi-line */
Test : System.Color {
	RGB = 255, 64, 128
}

TheSame : System.Color {
	RGB.Normalised = 1, 0.25, 0.5, // As with the simpler syntax you can add superfluous `,`
}

AgainSame : System.Color {
	RGB.Hex = 0xFF4080; Name = "Other"
}

Copy : System.Color {
	RGB = Test.R, Test.G, 125
	Name = "Copy"
}

AgainSame { Name = "OtherName" }

English Based Syntax

This syntax would exist in conjunction with the previous ones and more aims those who don't really know code since it becomes very readable.

Changes

• '@' statements:
  • @ is replaced with let
  • = is replaced with be
  • ... is replaced with with
  • . is replaced with from
• ';' statements:
  • = stays the same along with the parameter lists
  • Referencing variables like Test.R, Test.G becomes R, G from Test
    • To then continue on you just add and like R, G from Test and 125
    • To do ones before it you just add and also like 50 and G from Test and 125
    • Effectively and resets it (little different functionality from , to make it more english like)
  • ; is replaced with also
  • If you want to reference a previous variable you do X from Y = ... as in Name from AgainSame = "OtherName"
  • -> is replaced with just a space
• Comments:
  • // and /*...*/ is replaced with # (no multi-line)

Furthermore:

• let, be, from, with, =, ,, and, also are all reserved words and can't be used as variable names (though they can be used as function names)

Example

# This is a comment
let Test be Color from System with
RGB = 255, 64, 128

let TheSame be Color from System with
RGB Normalised = 1, 0.25, 0.5

let AgainSame be Color from System with
RGB Hex = 0xFF4080 also Name = "Other"

let Copy be Color from System with
RGB = R, G from Test and 125
Name = "Copy"

Name from AgainSame = "OtherName"

I've played around with a way to 'define' objects, defined objects are copied each place they are used. This means that they are extremely similar to #define in C/C++ (that's why I'm calling the definitions).

My current syntax is;

a : T = b
// Or to infer
a := b
// No support for this however since I don't see a need
a : T
// And function calls are fine however see the bottom note
a := B.x()

Where b can be any value such as an array, map, or integral type same as if you were passing an argument into a function. The type is a 'unique' thing since so far no types have really been used except in IR, I would propose either follow the IR type names (int, flt, str, bool, obj, dec) with support for arrays/maps like how you define 'object' maps/arrays i.e. x : [int : []flt] = { 3 : [1.0, 2.5], 5 : [5.3, 3.9] }

We could also expand the names to be like int, float, string, bool, object, decimal

NOTE: function calls

Function calls are a small problem because of the following reason;

• Should we cache the value of the call at the site of definition and copy that to each call
  Now we may want to do this because of something like this;

A : B
A.x = 2
val := A.x
A.z = val // clearly 2
A.x = 5
// is val 2 or 5?
A.y = val // should this be 2 or 5?

Now originally I would say it would be '2', however by the idea of definitions it would become A.y = A.x which would be 5.

Maybe we support this but also support 'references' which would emulate the second behaviour i.e. 5. This could be done through defining the reference like val := &A.x. This is actually easier to implement as it would just make each x = val into x = A.x instead, where as if you go the value without the & then we would need to make a 'copy' somewhere to use later on, perhaps we could implement this by placing the 'val' as a register (which typically just holds objects but I don't see how it can't hold a non object), which can be indexed as usual by a pushobj (which would push an object from a register onto the stack), this IR probably needs to be implemented anyways but this would require it.

NOTE: Add [Proposal] to the title if its a proposal or [Bug] if this is a bug
Further Note: Please make sure that it is clear whether or not your change will require new IR commands to be implemented.

NOTE: Add [Proposal] to the title if its a proposal or [Bug] if this is a bug
Further Note: Please make sure that it is clear whether or not your change will require new IR commands to be implemented.

NOTE: Add [Proposal] to the title if its a proposal or [Bug] if this is a bug
Further Note: Please make sure that it is clear whether or not your change will require new IR commands to be implemented.

For example in python you can use the * operator like x(*array) which translates to expanding the array as if it was a series of arguments i.e. the following;

arr = [1, 2, 3]
x(arr) # is just x( [1, 2, 3] )
x(*arr) # is x( 1, 2, 3 ) - note how the 'array' is gone

Since definitions don't allow multiple arguments due to their nature of being able to be typed i.e.
arr : []int = [1, 2, 3] should we be able to 'not type' them (thus allowing the values to not conform to the type UNTIL they are used in a function call) then later 'unfold' them i.e.

arr := [1, 2, 3, 5.0, true]
A.x = arr // error: not all types are the same
A.x = *arr // perfectly fine is just the same as A.x = 1, 2, 3, 5.0, true

Now the question is also what should the syntax be, I don't particularly like the * as it is too close to the pointer syntax in languages for my liking; I would prefer a more 'slice' based syntax i.e. arr[..]. This would fit the similar syntax of the proposed slices (#11 ).

Related to #8, #11

Current assignment rules dictate;

X.a = 5
// You can specify type
X.a : int = 5

However the syntax for defining a literal or a 'definition' is x : T = a which can be shortened to x := a, should we also follow suit and make assignments X.a := 5?? Or should we just automatically infer and make it just ? = ?? everywhere i.e. x = a or X.a = 5 or X = B::().

If so then what do we mean for X = B::() if X is defined vs not defined, are we assigning the label 'X' or are we assigning what X points to i.e. something more like *X = B::()?

Could we also allow X : B { ... } rather than requiring X = B::() { ... } since I don't like X = B { ... }, this would also basically help with backwards compatibility of v0.3 however we aren't ensuring that we have to be compatible just yet.

Very interesting, and I'm not settled on an answer yet.

NOTE: Add [Proposal] to the title if its a proposal or [Bug] if this is a bug
Further Note: Please make sure that it is clear whether or not your change will require new IR commands to be implemented.

Either;

A : B::C() {
}

or

A : B = B::C() {
}
// Which is the same as
A := B::C() {
}

The second syntax is more inline with literal definition which is a : b = c i.e. myNum : int = 5 or myNum := 5

Should we call them macros (due to them having a '#' and the fact that they should be viewed as resolved prior to IR) or should we call them attributes as they act more like a C# attribute.

The first release for DOML will be v0.4, this is to coincide hopefully with the C# version being complete, and hopefully a C++ and Go version. At this point all documentation for v0.4 should be complete and I'll archive it under a new folder and do a github release.

NOTE: Add [Proposal] to the title if its a proposal or [Bug] if this is a bug
Further Note: Please make sure that it is clear whether or not your change will require new IR commands to be implemented.

Introduction

While originally arrays could be implemented through supplying multiple parameters like ; X.Y = 1, 2, 3, 4 the addition of a requirement to statically allocate the stack and manage it (since it makes it more efficient and more like a traditional stack) means that this becomes more difficult with arrays since the 'sizeof' operations are exclusive of arrays, thus the addition of arrays are more relevant.

The source code would look something like this;

; X.Y = [A, B, C], [[D, E], [F], [G, H]]

There are a few ways this could be achieved with all requiring IR commands, for consistency I'll use vec to refer to an array (akin to vector in C++) instead of array this is mainly because it is shorter in characters;

Native Array Style

This simulates a traditional array structure. Effectively the IR command setup would be something like;

PUSH_INT_VEC 2 ; Pushes int array onto stack of size 2
SET_INT_VEC 5 ; Sets integer vector value to 5
SET_INT_VEC 8 ; Sets integer vector value to 8

This would effectively manipulate to something where each push would increment an index or pointer of sorts, though of course it would have to track and make sure the size of the array is less than its arguments. But however requires quite a few more IR commands (push_x_vec and set_x_vec where x is each type such as obj, num, int...), currently it would add another 14 commands. This could support both a hetero and homogeneous array structure though the inclusion of a heterogenous structure would require a generic push_vec.

Collapse

This effectively changes collapses the last set of values into the array. Effectively the IR would look something like;

PUSH_INT 5
PUSH_INT 9
PUSH_INT 200
MAKE_VEC 3 ; Make an array of the last three terms

This not only implicitly supports a heterogeneous but also easily allows for a homogeneous array. Though I would probably suggest for it to default to homogeneous and require a different command like makelist to represent a heterogeneous collection. This could be expanded to other types like dictionaries such as;

PUSH_STR "Bob"
PUSH_INT 5
PUSH_STR "Jim"
PUSH_INT 9
PUSH_STR "Jill"
PUSH_INT 12
MAKE_DICT 3 ; Make an array of the last three key value pairs (6 total values)

Though I would say that this could extend the stack a little too much. Also suffers from being slower (having to assign to the stack to then assign to a miniature array) and naturally means that making nested arrays slightly more complicated. This does however add only one extra command.

Mix of the first two

Effectively incrementally builds the array. The IR would look something like;

PUSH_INT_VEC 3 ; pushes integer vector of size 3
PUSH_INT 9
SET_VEC 0 ; Pops top value and sets to vector [0] (presuming vector is next top value)
PUSH_INT 2
SET_VEC 1 ; Pops top value and sets to vector [1] (presuming vector is next top value)
PUSH_INT 5
SET_VEC 2 ; Pops top value and sets to vector [2] (presuming vector is next top value)

This only adds a few commands; 8 in total, 7 for the push_x_vec variants and 1 for setvec, this is similar to the first two. I personally don't like this a whole lot since it feels messy, and in reality while it does save on space (only ever taking up one extra spot of space per array branch) it is just as slow as the second one.

Modes

This is effectively what I think is the best mix of the various ideas. The IR would look something like;

PUSH_VEC 3 ; Pushes vector of length 3
MODE 1 ; Set mode to index set
PUSH_INT 9 ; Pushes 9 into the vector
PUSH_INT 2 ; Pushes 2 into the vector
PUSH_INT 100; Pushes 100 into the vector
MODE 0 ; Resets mode to 'PushMode'

This would most likely be a homogeneous structure (with pushlist being seperate). Though you would have to maintain the integers. I would also suggest avoiding a pushintvec and rather just push a structure that's only purpose is to be indexed by the next push which determines its type.

Something like this (do note: that this is C# code, and isn't safe but does clearly demonstrate how such code works);

public static void Set<T>(int index, T object) {
    if (index == 0) {
        int length = runtime.Pop<int>();
        runtime.Push(new T[length] { object });
    }
    else {
        runtime.Peek<T[]>()[index] = object;
    }
}

Final Notes

Effectively how I see each of these methods is as follows;

• Native Array Style : Lowest Level but verbose and uses a lot more op codes
• Collapse : Nice and elegant though makes the stack considerably then it needs to be, though I'm sure one could have something like addvec to add to a vector (though that would probably require stating a length and things get complicated).
• The mix of the first two : Considerably slower due to the constant indexing perhaps? Though reducing the need for a large stack
• Modes : more elegant though opcodes should really only mean one thing and conflating what they mean could end up being disastrous (i.e. could a user add more modes?? That could lead to arbitrary code execution or other security flaws).

NOTE: Add [Proposal] to the title if its a proposal or [Bug] if this is a bug
Further Note: Please make sure that it is clear whether or not your change will require new IR commands to be implemented.

NOTE: Add [Proposal] to the title if its a proposal or [Bug] if this is a bug
Further Note: Please make sure that it is clear whether or not your change will require new IR commands to be implemented.

NOTE: Add [Proposal] to the title if its a proposal or [Bug] if this is a bug
Further Note: Please make sure that it is clear whether or not your change will require new IR commands to be implemented.

NOTE: Add [Proposal] to the title if its a proposal or [Bug] if this is a bug
Further Note: Please make sure that it is clear whether or not your change will require new IR commands to be implemented.

NOTE: Add [Proposal] to the title if its a proposal or [Bug] if this is a bug
Further Note: Please make sure that it is clear whether or not your change will require new IR commands to be implemented.

Introduction

Currently constructors (@ X = Y.Z ...) don't support parameters, this can be a problem as most constructors require a parameter of sorts, i.e. lets say you are creating a struct you can't really set the values of that struct without getting a new variant thus the constructor becomes important. Irregardless it also makes sense in this context to have constructors.

Required Changes

• No Extra Opcodes are needed
• Syntax Changes will need to be introduced these vary and are shown below

Parameters Ordered

This is where the order matters and no names are required. Example code;

@ Color = System.Color(255, 235, 201)

The use of (...) represents the parameters if there are no parameters you can either provide () or just not have the parenthesis (this means this isn't a breaking change to current code) furthermore the problem is with the fact it isn't particularly clear what you are passing in means and since you don't have access easily to the function signature it's hard to verify order it does however make pushing easier.

Named Parameters

This is where the parameters are named such as;

@ Color = System.Color(R = 255, G = 235, B = 201)

The equals are just to provide consistency though : could also be used (like R: 255, G: 235, B: 201), this does slightly extend the length though does allow for a more readable function. Though again the problem with this lays in the fact that this would require storing the type names and the use of those type names somehow (at the bare minimum as a dictionary from the string to int to represent order).

Named Constructors

This is where it takes a page from the 'book' of how setters/getters are performed i.e. example code being;

@ Color = System.Color.FromRGB(255, 235, 201) // Ordered
@ Color = System.Color.FromRGB(R=255, G=235, B=201) // Named

The parameters shown are ordered for simplicity though they could be named, this does enact a sort of clarity to what the parameters mean and allows for situations like;

@ Temp1 = System.Temperature.FromCelsius(25.0)
@ Temp2 = System.Temperature.FromFahrenheit(77.0)
@ Temp3 = System.Temperature.FromKelvin(298.15)

However this does mean that the names become quite a bit longer (you could remove the From though I would claim it's the main reason of the clarity).

Furthermore the syntax could represent a more text based version such as;

@ Color = System.Color : RGB(255, 235, 201) // Ordered
@ Color = System.Color : RGB(R=255, G=235, B=201) // Named

This uses the : instead of =, which means it's more stating that the System.Color is conforming to a standard so the default would be @ Color = System.Color : Empty() (or simply put just the ignoring of : Empty()).

My Opinion

The parameters ordered are nicer on parsing and would be faster to handle however are more annoying for a user to use and in that way I'm less inclined towards them and more towards named parameters, however naming the constructors themselves could enable ordered parameters to gain some kind of user friendliness and solves the issue of having to parse which constructor you are calling since each constructor would fit each name with the empty one having the default of just System.Color.

Support slices like in Go/Zig/D/...

Current syntax that most use is something like;

array := [1, 2, 3, 5]
A.x = array[0..] // from 0 to the end
A.x = array[..5] // from 0 to 5 (including the '5')

Maybe we would also want support for things like .length on the arrays?