This year, my December Adventure is focusing on StackTalk.
I think it's a neat idea that gives a high amount of expressivness for a lot amount of total investment.
Day 1
I already have a working parser & vm. Today was a syntax plugin for vim, getting a site generator up for StackTalk and trying to document StackTalk in an online manual
I would like to make at least one game with StackTalk during December. though, for the next few days, I'll probaby be focused on the manual
Day 2
Did some performance testing (and added basic support for runtimes other than node, at least for test.stk, found out that the in-language times was a couple orders of magnitude slower than I'd hoped. Thankfully, was able to port the definition to an ffi function, which sped things up by quite a bit. It's not a full performance review, but this language is -young-. More with time.
I also added some more information to the manual page. It was mostly related to objects and modules. I think ffi is next? And after that, I'd probably be looking at trying to make the playground more fully featured.
Day 3
Gave StackTalk it's own subdomain on my website, which you should be reading this from! It seemed too cool to relegate to just a subfolder on my site and I wanted to have an easier time publishing it than I had been. Having to build thes site, copy it to my static-site for my personal site, and then build and deploy -that- site was pretty clunky. Now I can just build.sh and deploy.sh, which is much handier.
Day 4
Now StackTalk has a first draft at a manual in place. There's more documentation that will be needed later, and certainly gaps in the current manual, but I need to -build- mor stuff in/for StackTalk before I write more, I think. Games, a better playground, and so on
See y'all tomorrow!
Day 5
Did a gaggle of things. Moved the stdlib out of stvm.js and have cli.js load it manually. This will also mean that different platforms can provide different implementations of a given functionality
Day 6
Took a break today, but did at least write this smol update.
Day 7
Did a lot of work factoring and documenting the standard library, especially by adding `StackTalk .load-file`
Day 8
More testing stuff, trying to set up defer
Day 9
Finally got defer working at a basic level
Day 10
Got temp working at a basic level, finally committed a lot of work in progress bits and bobs, some based on conversations in the catlangs discord
Day 11
I think I have enough of the language bits built to spend some time focusing on building up a better playground. Or, well, trying to work towards something like a web-UI ide? One thing that -has- happened is that more of the standard library is now usable on the playground, including things like temp and defer.
Day 12
Got FFI into a much less tedious place.
Day 13
I'm slowly working towards getting StackTalk's browser libraries up and running. A lot of that has been work into trying to figure out how best to manage the fact that the cell abstraction used by the wrappers so far didn't have any support at the FFI level.
The biggest consequence of that was having to write FFI functions, and then functions that wrapped the FFI functions and did things to them. Overall kinda tedious, and it also leads to splitting understanding across two places in code.
My first attempt at addressing the issue was to sketch out some sort of Better FFI object in StackTalk. The working name was Alien. The next morning I realized that there were a few specific interactions I was looking for:
- Being able to wrap a JS value in a StackTalk object. I call these cells atm
- Being able to access the JS value in ffi functions without a lot of ceremony.
- Being able to use modules on a newly created cell
- Being able to run quotations inside a newly created cell
For the first, I already had vm.newCell For the second, I added vm.subject which grabs the top of the mevalue stack. Conventionally, this is the array/Map/DOM Node JS value that the FFI words will want to interact with, for a given wrapper object.
For the third, I added the ability for vm.newCell to be given a list of modules to apply to the freshly created wrapper object. For example:
StackTalk: is-obj[
modules: [ -/- @ ]
js: "async () =>
await vm.newCell(vm.modules.keys(), '#array')" ffi
]This reduces wrapper calls related to using modules
For the last thing, I made it so that a module is used, if it defines an init function, that function is called on-use.This means that vm.newCell can now execute arbitrary code. Which is why it has been changed to be async, but it also unifies how modules that need to do some setup work in general, rather than leaving loose functions in the Lobby for setting up objects
For now, at least, the Alien idea is shelved, these other changes cover the bases I was thinking of trying to cover.
Overall, I like the direction this stuff is going, and it gets me every so slightly closer to being able to build a heckuva browser workspace, hopefully
Day 14
Did a lot of things. Testing out DOM with playground. Need to async-safe vm.eval Added curried/fried quotations
Day 17
I did a lot of things since the previous decadv update, but I will try to list them out more this time.
The overarching effort I've been working on is implementing the StackTalk playground using StackTalk as much as possible, rather than only in Javascript. This has meant a lot of building up FFI for various JavaScript browser APIs, like the DOM, the window object and so on.
The first big thing I want to showcase is the HTML/DOM builder module:
HTML ask[
#app: attach
build[
div[ transcript: id ]
textarea[ code: id ] br[ ]
div[ error: id ]
button[ run-code: id Run: @ click: on[ void
#code: DOM .querySelector ask[ value: get ]
Playground .runCode
] ]
button[ get-share-url: id
del[ "Get Share URL" @ ]
"(currently out of order)" @ ]
p[
a[ "./manual.html" href "Learn more" @ ]
]
]
]This is the current (as writing on Dec 17th, 2025) code that defines the UI for the playground. It uses a DOM builder DSL defined in browser.stk
Another thing I want to show off is stkweb.js. It adds support for stacktalk browser script tags, so you can use stacktalk for bits and bobs of web things.
<script async src='./stvm.js' type='module'></script>
<script async src='./stkweb.js' type='module'></script>
<script type='stacktalk/lib' src='./core.stk'></script>
<script type='stacktalk/lib' src='./browser.stk'></script>
<script type='stacktalk/lib' src='./libplayground.stk'></script>
<script type='stacktalk' src='./playground.stk'></script>There are currently two supported tag types. The stacktalk/lib type is for scripts that should be added as libraries before other scripts. The stacktalk type is for scripts that should be executed as soon as they're loaded/parsed. You can use either src or the contents of the tag to indicate the script to be loaded/executed.
I've also added the ability to use module/extend to extend modules. This is meant to help specialize modules for specific environments, like adding playground dump support to arrays and dictionaries.
There's a number of other miscellaneous changes and fixes. tokens-of now has %w as an alias, and it correctly handles nested quotations. use has been updated to marked as asynchronous. The StackTalk object got the ability to make new StackTalk VMs via make-vm which also adds a new #stacktalk-vm module. There's a new FFI object, and a simple-wrapper module that makes writing wrapper FFI objects for mutable JS object properties very easy.
Overall, glad with how things are going for StackTalk.
Day 26
The last nine days have been a journey of trying to figure out how to rebuild the site builder with StackTalk's newest feature: Splitwords.
If a quotation contains a token that starts with : then the quotation is turned into a . A proc is an object that contains a proc stack, which is the quotation with the "main" body of the code, and then for each splitword, there is another stack that contains the relevant code.