luxferre/clyx
1
0
Fork 0
Code Actions Activity

updated readme

Browse Source
This commit is contained in:
Luxferre
2026-07-03 12:36:14 +03:00
parent 05b334cdb4
commit f0918f8895
1 changed files with 12 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+12 -2
View File
@@ -87,14 +87,24 @@ Similarly to [LVTL](https://codeberg.org/luxferre/lvtl-x) and [LTTB](https://cod
Additionally, this name can be viewed as an acronym hinting at the order some binary operations pop their operands from the stack: "Compute by Loading Y, then X".
### Is this language high-level or low-level?
More of a high-level one (because you don't have any memory control), but in fact it can be both.
Clyx combines the conceptual simplicity of Forth (and concatenative/RPN programming in general) with list definition syntax, list manipulation and metaprogramming capabilities of Janet and Tcl, making it much more practical for everyday tasks. At the same time, you can build abstraction levels as high as you need to, making it a nice choice for creating custom DSLs (domain-specific languages), especially with the `next` word that pushes the next logical token onto the stack, allowing to change token processing order.
### Why not just pick up a Forth instead?
Forth is good if you are fine with only being able to push integers onto the stack and building all your abstractions using direct memory access. Clyx, on the other hand, does not have direct memory access because it was designed for the systems that might not even give you one, but you can do so much more with the data types that it allows you to push onto the stack without involving any trickery.
Clyx combines the conceptual simplicity of Forth (and concatenative/RPN programming in general) with list definition syntax, list manipulation and metaprogramming capabilities of Janet and Tcl, making it much more practical for everyday tasks. At the same time, you can build abstraction levels as high as you need to, making it a nice choice for creating custom DSLs (domain-specific languages), especially with the `next` word that pushes the next logical token onto the stack, allowing to change token processing order.
While diverging from some "purity" aspects, Clyx is a decent choice for newcomers that want to try out a totally new programming paradigm without investing too much time into fighting the language's quirks.
### What do I need to do to create my own Clyx implementation?
Just port the core interpreter along with the 48 primitive words, stubbing out the words that cannot be supported by the target platform if there are any, so that if a program that e.g. uses `nopen` runs on a non-networked host environment, or a program that uses `hseval` runs on a C-based interpreter, then the user would get a clear message that an unsupported core primitive word has been encountered and the program has been terminated because of that.
Apart from that, your implementation needs to be able to load `lib.clx` (standard library source) upon initialization, and `clyx_repl.clx` upon passing no parameters (if it is CLI-based).
### Doesn't `hseval` primitive make Clyx programs non-portable across different implementations?
Yes, it does, because it works differently across different host languages (and Clyx implementations are allowed to not support it at all), so it must only be used as a last resort when any other attempts to interact with the outside world are unsuccessful. Additionally, using `hseval` introduces extra security risks. Nevertheless, this primitive had been added in order to enable some host-specific interoperability that would otherwise be impossible or very cumbersome to implement, such as browser-based deployments.