Closed yurapyon closed 1 month ago
the status quo for datastructures is
0 cell field >some-field
cell field >another-thing
constant size-of-thing
create instance-of-thing size-of-thing allot
0 instance-of-thing >some-field !
instance-of-thing >some-field @ .
an 'object' is a hashtable where the keys are strings and the values are anything else in the case of forth, the values may just be cells. nesting of objects is just when a value is a pointer to another object.
adding hashtables isn't a huge deal but is it necessary?
and the real question is: what makes forth inaccessible?
its not really a difficult language just its very 'designed' and unique you have to listen and pay attention
without well-defined syntax it can be hard to just zone out and write a pattern, until you invent and get used to those abstractions for yourself also debugging can be pretty fickle when things get complex ie compile words
Forth is nice when it reads like plain english and this should continue to be considered and optimized for 👍
would be cool to take influence from other languages that are stack-based, concatenative, untyped or just seem forthy:
also look into other VMs or actual microprocessors for bytecode ideas
key thing to note is that Forth is more on the side of 'jank' than it is on the side of 'conventional good developer experience'
'accessibility' isn't a main goal of this project classically, Forth is something that takes time to understand and once you 'get it' then it appears simple but it does require broader context
thats fine 👍 and this project doesn't aim to lower the amount of context necessary to understand it. this project is to create something thats "easier to dig into", not necessarily something that is "quicker to dig into"
if JS style objects are added, would that make the language more accessible? :)