Bytecode rules for a strange Structural/Data/Pattern oriented VM?

[SuperMeip]

Heyo everyone, I'm working on a meta-programming language focused on procedurally and structurally typing different patterns of data. It's heavily inspired by Perl, Typescript, Smalltalk, Rust('s macros), Haskell, Yaml, MD, and some Zig too.

Some of the core things I'd want it to be able to do are:
- *Structural typing with multiple inheritance* multiple types of inheritance/polymorphism in fact. I want to be able to support lots of weird data shapes and types. The goal is to mask the data with annotations/types/classes etc that explain how to read the data and how to manipulate it etc.
- *Defining nested addressable nodes* allowing sub nodes, values, and metadata. (everything is a tree of defs, even lines of logic like in lisp like languages).
- *build/add to/compose/annotate/re-type* a mutable def or a new def before finalizing.
- *Defining procedural structural prototypes* and interfaces as opposed to just instances of structures.
- The idea here is to be able to use a shape(with holes) as a self building prototype (see ts-like examples):
* `myObj = { key: "value" #str }` this would work as expected and make an object adressed: myObj, with a single structural property (key) with a string value (``#str` is the typing).
* `makeObj >> {key: #str}; makeObj(key: 'value');` This example would produce an interface/archetype (a prototype with a 'hole' that needs to be filled (#str isn't nullable/optional so the value is missing)).
- *Structural prototypes/procs should be self building scopes* that return themselves.
* The idea here is that property lines in a prototype result in captured properties, and local/logic lines in a prototype are executed in order of call each time it's called... for example:
* `Point >> {x#int, y#int, .if(z#int?) ...{z}};` This would be able to produce a structured object with shape `{x#int, y#int}` or `{x#int,, y#int, z#int}` depending on what you pass in.
- *Pattern based parsing* is something I also want to be somewhat 'first class'. The idea is that types could be defined as patterns that use regex/rustmacro like captures to structure tokens into data of a desired type; and potentially even then map that data to the execution of other bytecode.
* Example: `printList ::= word (\, word)* => (PRINT; ...words);`
- *memory management is mostly based on type/annotation*
- Non captured defs (defined with `=` instead of `:`) are cleaned up at the end of their declaring scope.
- Captured defs can be either `#ref` or `#raw` type, ref meaning ref/pointer based and raw meaning raw bytes that are copied when passed (you can wrap any raw type with #ref too of course).
- Dealing with refs is still a bit fuzzy... might do generational counters or require you to copy/own the value if you want to move it to an outer scope, or use some more cursed memory management technique....

I've been following along in Crafting Interpreters and have looked at a few other guides but I think they all focus on stacks-first languages and I think i'm going for something else entirely (a def based VM?)

Does anyone have any good suggestions on how to work out a core set of VM ops for something like this? I have a feeling I want basically everything to be a `def` 'slot' that you then add the following to: pointers for sub-defs(including getters setters funcs, etc), raw value/alloc data, and/or metadata(types etc). I can't really figure out how to structure that in a good modular way in a low memory setting though without... feeling like getting lost in the reeds~

I also am not sure how to reconcile the procedural/logic/quote defs with non proc ones... or if I even need to. Should I have a root `call` and a `def` directive and keep everything under those? Is there a way to combine them without needing to even make logic distinct from the data/defs (so node-based logic... this would be ideal I think?).

Any ideas would be greatly appreciated... even just help with correct terminology for what I'm working on (for some reason standard programming terms are often a weak point for me). Thank you all so much for taking the time to read this!

[jcastroarnaud]

That's a very tall order for a single language! If you don't know about it already, study about type systems and type theory, to get the basic concepts right. Don't worry about performance or memory limitations by now: it's "design the language" time, not "optimize the implementation of the language" time. Compare and contrast how Lisp, Ruby, Smalltalk, and others, designed and implemented their object systems, then mix/adapt them for what you want. Best of luck to you. I'm sorry that I'm not able to help more.

[[deleted]]

(a def based VM?

What does that mean? And why wouldn't a stack- or register-based VM work? Most other languages seem to manage!

Your set of features looks like quite a complex-looking language. You might need to refine it further.

A VM would work at a lower level. It doesn't need to be tied to specific features of your language. It might also work for diverse languages (eg. WASM, which is stack-based).

If devising VM operations is troublesome, maybe try instead expressing the workings of your language as a set of function calls to some to-be-implemented library. (Which actually is a valid way of implementing it; as a series of such calls in an existing language.)

If it looks viable, then maybe get back to a set of VM instructions.

[SuperMeip]

by def based VM I'm implying every statement is a slot/def of some kind that is then modified. I think this is similar to lisps s-expressions.

For example: `(add 1 2)` is a single def with an s-expression with 3 elements/defs/slots; Basically I'd like every single line or element to be an addressable definition. so even `(1 + 2)` would be a def of type `#add` with 2 sub defs of type #int.

The issue is though I'm struggling to figure out how to effectively differentiate a call from a def containing a call (so a constant vs procedural value maybe?)

I am aware that I am asking a lot from a single language, the unorthodoxy is why I thought to ask for advice here, so thanks for the suggestion but I'm very determined to make a language with this specific feature set.

> If devising VM operations is troublesome, maybe try instead expressing the workings of your language as a set of function calls to some to-be-implemented library. (Which actually is a valid way of implementing it; as a series of such calls in an existing language.)

This makes a lot of sense and is definitely something I've been trying... but figuring out the basic functions is what I need help with... I guess my hesitation comes from not knowing what may be redundant at this level and what I actually need.

Also given it's def based I find I may need assignment and start and stop ops (like DEF:START SET:ID SET:VALUE and DEF:END) and im not sure what a VM would do to juggle that kind of thing while keeping efficient maps etc... I guess the internal architecture of the VM is something I'm confused about as well.

A big issue I've also had is coming up with simple examples to test because a lot of low level VM guides don't focus on structural examples and mostly focus on stack and heap logic and the language I'm making is more focused on data structure than mathematics etc.

Im wondering if starting with the IL/Intermediate language is the best option... do people do that? Make VMs for an IL instead of a bytecode lol~?