\ Saneforth
Forth in under 100 lines of GNU C99.
[0] Abstract
Forth is a extremly powerful, typeless language, however, imo, its elegence
is offen tainted by small, unelegent standard peices of code, which limit
hackability in a way that simply isn't forth-like.
For example, in regular forth, literals are quite literally baked into the
interpriter, to the point where changing this behavior, adding debugigng
features, anything - would require special hooks, weird hacks, and general
inconvient, uncomfortable and akward hacking.
Saneforth looks to be remedy this problem, focusing specifically on
simplicity, modularity, extensibility, and most importantly
grockability - focusing entirely around the sane phliosophy[1].
Grokability - The ability understand completely and intuitively
Possible solutions
To me, this is very un-forth like. ABLEforth solves this issue by putting
parsing words front and center stange, there is no built-in literals, all
data-types are handled the same way.
[1] Sane phliosophy
The best way to define the Sane phliosophy, is to contrast it with similar
phliosophies.
Worse is better
Simplicity - simple implementation and interface.
- It is more important for the implementation to be simple than the interface.
Correctness - The design should be correct in all observable aspects.
- Correctness can be sacraficed for simplicity
Completeness - The design must cover as many important situations as is practical.
- Completeness can be sacrificed in favor of simplicity.
- Completeness can be sacrificed in favor of correctness.
Consistency - The design must not be overly inconsistent.
- Consistency can be sacrificed in favor of simplicity.
- Consistency can be sacrificed in favor of completeness.
- Completeness can be sacrificed in favor of correctness.
Sane
Grokability - Unsterstandable implementation and interface.
Correctness - The design should be correct in all observable aspects.
Extensibility - The design should be trivial too constuct any use-case.
Consistency - The design must be consistent.
How does Forth work?
Forth is essentially broken up into 2 parts:
- A VIRTUAL MACHENE that itterates over an array of code pointers.
- A "SHELL" that interprits text into an array of code pointers.
A normal forth program will follow this diagram
"string" -> shell -> {array} -> forth_vm
core: alloc { =
varables: mem stack rstack dict
memory: read write move
parsing: int float char str
math: + - * / %
bin: and or xor invert >> <<
\ Sane Forth Standard
Taking inspiration from the simplicity of the scheme standard, and with
admiration of the unified Emacs Lisp ecosystem, Saneforth looks to bridge
the gap between forth and the modern age - creating a dynamic and growing
ecosystem of tiny peices of software that enjoy the benifits of the tiny,
infinintely extendable forth language.
The scope of this project is large in abition, and small in implimentation,
The roadmap looks something like this:
1. Release version 0.0 of the standard
2. Release an ultra-tiny non-optomized interpriter, written in C99
3. Play around for a couple weeks/months, itteratively improving
(v0.1, v0.2, v0.3...)
4. Release version 1.0 of the standard
5. Release a "Standard Library"
- Distinguish between 2 types of "Libraries"
> Libraries -- (designated as "lib")
Libraries follow a pattern <library>:<word>, and seperate
themselves from the base lang.
(ie. file:write)
They add well-defined words to the lang, and do not change
base functionality of the lang.
> Extension Libraries -- (designated as "elib")
Extension libs are seprate to warn the user, these libraries
take advantage of the full power of forth.
They are not well-defined, and are allowed to have
single-character words, prefix words (Features[1]) , and even
extend and replace base-words.
There is no limit to elib's power, so be very very carful with
them.
(example
" - prefix word -- reads until the next " and compiles that
into a null-terminated string.)
6. Start developing the ecosystem
(taking advantage of the power of forth to impliment everything in
trivial sloc, making it almost infinitely hackable and extendable)
- Text editor (>300 sloc)
- Core util replacement {lib} (few thousand sloc)
- Shell replacement {elib} (>150 sloc)
- Text-based browser
- Much much more.
Note: I would like take a second to explain how forth programs are
written. Typically you write a command language for the specific
task you are doing (for example: editing) and then you
write features around that language.
(so like
up
down
left
right
writechar
grabchar
copy
paste
etc...)
For the text editor, you would probably add an interaction
layer for the input that:
- updates a visual repersentation of the doc.
- binds short-cuts to specific keys or key-combinations
(like a tiling wm)
However, it is imperative that you give the user access to the
underlying forth shell. This is what turns the editor from a
cool toy, to the perfect hackers lanugage. Not seperating
editor scripting from the editor itself, this allows for
infinitely powerful scripts, even changing behavior at runtime.
(ie. simple example, redefine `k` as "go up 2" instead of 1)
Note: All of this up until this point, is utterly microscopic amounts of
code. >3000 sloc type small.
Like I said, large ambition, tiny implimentation, code is art and
should be built tiny, then audited and edited to utter perfection.
None of this should take very much work at all.
7. Optomizing compiler
(biggest and hardest part of the project)
- Lookahead
- Loop unrolling
- Way more shit than peephole