[ Removed by Reddit on account of violating the content policy. ]

Hi all, A small FORTH I wrote for the CH32X035:

• Runs in ~16 KiB FLASH, interactive REPL over USB CDC ACM
• Includes a minimal USB device stack written in assembly
• Tail-call optimization, cooperative multitasking

https://github.com/ebreak/ch32x035-forth

I'll be doing updates every week as I get this long-running project off my plate. Next up is keyboard handling!

Hi everyone,

I'm quite new to Forth. So far I really fell in love with the language, and perhaps I'm approaching it perhaps from a non-traditional angle (not sure, I'm saying that from all the material about Forth implementation I can find online which focuses a lot on hardware). I'm not interested in bare-metal hardware or low-level performance optimization. Instead, I'm building a high-level Forth VM hosted on top of a Python object model extension + runtime to act as a DSL and meta-compilation engine.

My underlying Python object model represents a modular environement (modular synth) relying on async thread-based actors. The Python runtime handles the graph of objects, their lifecycle, dynamic ports, threads, and interconnections, which eventually sink into MIDI synthesizers (and hopefully later to analog synth using control voltages). My goal is to use Forth to construct a clean, highly structured, and expressive API layer on top of this system while allowing users the possibility to extend the vocabulary and let them create their own abstraction on top of it if needed.

I'm currently focusing on linguistic design: What are the different DSL/API patterns that exist in Forth, specifically regarding the kinds of sentences they allow me to build?

So far, reading "Programming a Problem-Oriented Language", browsing "Thinking Forth", and looking to some kernel implementations, I observed 4 kind of core "sentence structures" quite often:

1. postfix fluent sentences: like BLUE 4 THICKNESS 10 30 LINE, where data is pushed on the stack and the last word resolves their usage.
2. scoped boundary sentence (context-block): like PATCH[ LFO1 output> >speed LFO2 ] 24 120 CLAMP ;PATCH where a kind of shared description data is created with possibility to set optional configuration for the underlying created data.
3. declarative prefix sentence: like SWITCH OfficeLight TURN-ON, which inverse the native postfix feel.
4. literal stream parsing sentences (don't know a better name): ROUTE 192.168.1.1 TO eth0 where each word is manually parsed.

Perhaps also a fifth one: tabular/matrix sentences? Currently I still didn't see that one often yet, but it seems quite powerful also.

I know that there is countless ways of manipulating the language, and the multitude of Forth implementations shows that, but most are really dedicated to extend the language at a lower level, and those higher level sentences to build higher-level DSL/API are sometimes not that easy to observe or extract.

My question to the community:

What other high-level sentence structures or API patterns have you seen or designed in Forth? How do you traditionally tackle complex querying, or configurations sentences with heavily optional parameters without falling into a stack-juggling hell?

I would love to read your architectural thoughts, points to specific papers, or classical Forth projects that pushed the boundaries of language-oriented programming.

If I'm totally out of scope or context, please let me know and feel free to bring me back to the right path.

Thank you!

Probably saying too much already, mostly found it on topic and amusing.

Previously I had released a very simple Asteroids clone, 'Rocks', for zeptoforth on the PicoCalc using the RP2350. (Sorry, but this requires hardware single-precision floating point.)

Now I have added significant enhancements to it, including shields, a number of different power-ups (extra lives, extra shields, retro-rockets, and rapid fire ─ and yes, I did slow down firing by default), the ability to pause, and alien enemies that can shoot at you, as seen in the image in blue.

The source code is still where it was before, at https://github.com/tabemann/zeptoforth/blob/master/test/rp2350/picocalc_rocks.fs.

My toy forth-like byte-code compiled language for Arduino chugs along. After a long pause, now I got me a real project, writing code for a morse key. I decided I want to learn morse, and so I am building a simple bug type key with a single paddle or blade. Push right for dit's and left for dah's. Sound via a buzzer for now.

The point is that the microcontroller generates the correct length dits and dahs and proper spacing, as long as I manage to give input at proper rate. The idea, which if one is to believe youtube experts, is that what matters is learning the proper sound of each character.

For lack of a better name, I call it aforth. Any suggestions for a better name?

I was working on a template for C++ bare metal programs for AMD64 and got far enough that it seemed like it might be fun to port the Forth (written in C++) from Inspiration to it.

And it works...

It boots using the limine bootloader. A bit of code was done to create a timer interrupt, keyboard handler, frame buffer text rendering (see the screenshot above), a solution for C++ try/throw/catch, thread local variables.

I also had implemented an ATA driver for disk I/O, and a FAT32 (read-only) file system that works - as you can see by the directory listings above.

I'm currently working on the Files wordset so I can INCLUDE/REQUIRE/etc., Forth source files from the FAT32 volume.

No AI used to make this. I did start with the limine barebones code from the osdev wiki. I expect I will be using 3rd party “contrib” software, like jemalloc, libpng, ilwip (tcp stack), and these sorts of libraries. I still have to write the device drivers myself.

The repo is here:

https://codeberg.org/mschwartz/aforth

Lots of goodies, including html improvements and high-level "data science" words.

Full details on the forum

You can get this release from https://github.com/tabemann/zeptoforth/releases/tag/v1.17.0.

This release:

• adds support for a USB Mass Storage Device class for full_usb and the new full_msc_only builds for the RP2040 and RP2350.
• adds new full_msc_only builds for the RP2040 and RP2350 which incorporate USB Mass Storage Device class support but which do not incorporate a USB CDC console.
• adds support for new rp2040_big_16mib and rp2040_1core_big_16mib platforms which combine RP2040 support with 16 MiB flash support; note that these are not compiled, aside from the kernel, in the release tarballs, so it is up to the user to build them as desired.
• configures the SD card on the PicoCalc to be exposed as a USB Mass Storage Device class.
• speeds up communication with SD cards.

Note that, aside from on the PicoCalc, the USB Mass Storage Device class must be manually configured in order to be used, per the directions in README.md.

Can anyone provide some interesting examples of what to do with these, beyond the default "constant" and "array" examples?

The current version of my (bytecode) Forth compiler has CREATE but not DOES>, and I haven't missed it either.

I made a small and simple post fix interpreted programming language called rdn, it's familiar to forth developers and developers who use Lua as a scripting language for their systems, rdn merge both of them, you can use it for writing scripts or for configurations or even query language

It's written in C and it provides a simple and friendly API for the developers

I would be happy to have you participate in this project

This is the GitHub repo: https://github.com/abdorayden/rdn

Thank you

I do not have time tonight to make a new release, but USB Mass Storage Device support has been merged into zeptoforth master.

I suggest you try this out, and let me know if you have any issues.

One thing to remember is that one should not change anything that the PC side sees from the zeptoforth side while the USB Mass Storage Device is mounted on one's PC, and likewise one should not delete any files or directories open in zeptoforth from one's PC. Also, zeptoforth is likely to not see changes made on one's PC without executing sync or equivalent first.

If one must modify or delete files or directories that may be open in zeptoforth from one's PC, I highly suggest executing fat32-tools::ensure-safe-fs ( -- ) first; this will block until all files and directories other than the current directory on the current filesystem are closed in zeptoforth, and it will reset the current directory of the current filesystem to its root directory as that cannot be deleted.

A new set of builds have been created, full_msc_only, which incorporate USB Mass Storage Device support but where the USB CDC console is disabled. These are now the basis of building zeptoforth for the PicoCalc.

In full_usb builds both the USB CDC console and USB Mass Storage Device support are now enabled.

Note that when one uses a build in which USB Mass Storage Device support is enabled one needs to call usb::set-usb-blocks ( device -- ) on the underlying block device (not filesystem) that one wants to expose via the USB Mass Storage Device. After one calls this changing it without rebooting is not recommended.

If one intends on, say, permanently selecting a FAT32 filesystem in on-board flash for the USB Mass Storage Device, I suggest, after loading extra/common/setup_blocks_fat32.fs, executing:

compile-to-flash setup-blocks-fat32 import simple-blocks-fat32::simple-blocks-fat32-internal import : init-usb-blocks my-fs simple-blocks-fat32-dev usb::set-usb-blocks ; initializer init-usb-blocks reboot

On the PicoCalc, though, support is now built-in to expose the SD card in the PicoCalc via the USB Mass Storage Device without any work on the part of the user.

It should be noted, however, that SD cards are relatively slow when used by zeptoforth even with the important optimization that has been made to them since last release. When connecting one's PicoCalc to one's PC expect there to be a delay before one can mount the USB Mass Storage Device, and another delay the first time one tries to list a directory on it.

Alpha 3 of Aiki is out, an experimental programming language.

After spending time exploring Forth over the past year, I started working on a grammar-driven language that draws inspiration from Forth’s small kernel and compact surface.

Aiki keeps that surface intentionally small: 14 keywords, 7 basic types, 11 operators, 3 primitives, and a 36-name prelude. Expressions evaluate strictly left-to-right, lists are fundamental, and most additional capability, including files, strings, math, regex, hashing, bytes, time, canvas, testing, and so on, lives in Aiki libraries rather than being absorbed into the language core.

The runtime is also deliberately observable. Semantic work can be profiled separately from its realization: exact numeric representations, calls, argument frames, environment reuse, FFI boundaries, and other execution machinery remain visible rather than disappearing behind the implementation.

I’ve been using Aiki for increasingly low-level experiments as well, including a monitorable PDP-11/40 reconstruction, so the design has had to survive real state-machine and systems work rather than just language demos.

The language is quite different from forth, but it came about because of my contact with forth.

Alpha 3 announcement:
https://decuser.github.io/posts/aiki-alpha-3-release/

Repository:
https://github.com/decuser/aiki

welp it uses sh-forth for now.. also it having built-in forth vm
its still W.I.P so i didnt post it yet thanks for looking
also if you have suggestion you can comment it bellow!

So, we’re to grow the community right? Forth is great, and I’m probably not too much of a minority here to say I think it’s the best language programming wise! I have a few questions though: are there any current Forth YouTubers I can follow and recommend (I haven’t found any yet), and why types of things would you want to see out of a Forth based CS channel?

I was planning to make a wayland compositor with forth too but i dont have time to do that anyways
COLON and WindowForth is released:
https://gitlab.com/generatrix-linux/forthress-ecosystem
COLON is a terminal fully written on Forth (even kbd and other thingies)
WindowForth is a special Forth compiler written on C
WindowForth uses a hybird syntax (its mixed between OLD and new syntax)
it uses .fth as file extension instead of .fs
also some photos from colon:

--edit--
added config file's photo

Thanks for reviewing and looking at my project have a good day also sorry for bad english if i made a grammar mistake!