Remarks & small issues

[fisian]

• zero (maybe begin -numbers, +numbers or both with 0)
• some action return values (which set the state) seem not right
  • action pop (breaks stuff because it overwrites state to values taken from stack)
• types: split into declarable and effective (written to stack)
  • not all in the same map (e.g. put number in a different map than +number and -number)
• debug output TYPE FOR 3 should be eval
• block declaration assumes that every 2nd token is a type
  • this could change when namespaces or other things are introduced
• block declaration automatically pushes block id to stack (a bit annoying & requires a working pop action)
• nested block declarations don't work

All in one issue because I was too lazy 😐 and some of those are just 1 change in the code.

[Neverbolt]

• Zero is indeed a bug and will be fixed
• will need to look into the return values
• what do you mean with declareable and effective stacks?
• will fix debug output for eval
• one of the signature points of q is that it always consists of 'type' 'value' pairs
• automatically pushing block id to stack will be changed to only anonymous blocks
• nested declarations should work, though it is possible that it died with the last reactor

[fisian]

With declarable and effective types I mean +Number and Number for example. The declarable types are how they appear in code and effective types are how they appear on stack. Example: I define a positive number: qqqq q When it is written to stack it is just a number and the interpreter does not care if it is positive or negative. (* additional thought: see below)

The thing to change here would be to put '-number' and'+number' into a different map than 'number'.

The benefit of this is that it is clear, which datatypes can occur on stack and be popped by actions.

The same thing applies to lChar, uChar, sChar which can all be treated as char (or even string maybe).

*PS: As -number and +number have different usages with blocks/actions they could be treated differently on stack too. However this would make type handling more difficult and go into the direction of dependent types.

[fisian]

I really just mean that the 'keywords' -Number and +Number, etc. should be separate from the 'type' number, etc.

[Neverbolt]

Okay I understand your thought, the thing is that there will be a parser that is separate from the interpreter, which would mean that this problem between representations will disappear.
This parser frontend would be especially helpful to allow for running close dialects (@LlinksRechts is apparently not going to be 100% syntax compatible with his Rust version) and to allow way better error messages, since the ones available now are ridiculous.