drwhut / decision Goto Github PK

It doesn't make intuitive sense for one to be "more" than the other.

Also make sure they can't be mixed with other data types.

This is just here as a reminder, as a lot has changed.

With the new sheet structures in the function-metadata branch, data like the names of functions is duplicated across multiple sections of object files.

As of now, the optimisation stage will change every other instruction if needed every time bytecode is removed!

Instead, maybe "mark" bytecode to be removed over time, then remove the bytecode all at once at the end, changing instructions if necessary?

This would allow for an infinite amount of "local variables", and we could reduce the number of registers in the VM.

We should also make the stack dynamically allocated so it can grow and shrink.

Instead of storing the socket's connections in an ordered list, where it would take O(log n) time to find, why not implement a hash table? That way, it would be O(1) time to find the socket and it's connections.

We will always need to put down a value in Decision code anyway...

It's annoying to have to type 1.0 instead of 1.

Having multi-line comments will be difficult to work with when it comes to GUI editors storing their metadata.

Maybe have anything after a > be a comment on that line?

This way in the source code we have three defines for the major, minor, and patch number. This would help us later on when we want to compare version numbers.

With the VM now storing the types alongside the data in the stack, we should now be able to make custom functions with vague data types.

Values would still have distinct types in the VM, it would just mean that the VM would decide how to use them depending on their types.

We could always optimise by having more specific opcodes if we know for a fact a given value will be a distinct type.

Right now, all strings are stored as byte-character arrays. They should be stored as wide-character arrays instead so that unicode characters can be used in Decision.

e.g. And(5, 17) would output 1.

This will allow GUI editors to directly get the input and output names from the Decision library.

This would also allow us to automatically update the user manual reference if we had a way to export the data.

Since the future GUI Editor will most likely involve the Godot Engine in some capacity, it doesn't make sense to install CMake for one and SCons for another.

This way, when we get around to having Decision shared library files (i.e. dll, so), it can just return a Sheet with the C functions defined in it.

Right now, it is very error-prone.

Instead of the order of insertion, order lexicographically, and use binary insertion/search.

This way we can later check to see if an object file is incompatible.

This way, we don't have to remember to update the core reference every update.

For example, Concatenate.

This would allow Decision to be easily embedded into other programs.

e.g.

PUSHB 0x1
POP

For example, if a node has been misspelt.

This is here as a reminder for me to make sure the compiler doesn't try and load object files from v0.3.0.

Should probably implement a getter and a setter function instead.

e.g. scanf_s, sprintf_s.

With the -pedantic flag, gcc throws a hissy fit that doing this "isn't part of the ISO C Standard".

Instead of directly putting the function pointer in the text section, maybe put a pointer to the CFunction struct instead?

For example, if someone is dragging a wire from an output execution socket, the function would return all node definitions with an input execution socket.

The best way to do this is to have the biggest elements of structs first, and the smallest elements last.

This way, we can test Decision continuously on all 3 platforms: Windows, macOS, and Linux.

Give the user the option to either generate a static or a shared library, and have the executable just use the functions from the library.

We would need to separate the main function into a separate file, though.

It should give a VM runtime error.

This happens a lot in the code.

For example, Equal(true, true) would return true.

Learnt some stuff at university that would seriously help with Syntax Analysis.

Not actually sure what happens - we want defined behaviour here.

This guarantees type safety - especially with the C API.

What if someone changes the contents of the file after it is compiled?