#parser
I'm starting a series of blog posts, in which I write a #bytecode #compiler and a #virtualMachine for arithmetic in #Haskell. We explore the following topics in the series:
- Parsing arithmetic expressions to ASTs.
- Compiling ASTs to bytecode.
- Interpreting ASTs.
- Efficiently executing bytecode in a VM.
- Disassembling bytecode and decompiling opcodes for debugging and testing.
- Unit testing and property-based testing for our compiler and VM.
- Benchmarking our code to see how the different passes perform.
- All the while keeping an eye on performance.
The first post of the series that focuses on writing the #parser is now out: https://abhinavsarkar.net/posts/arithmetic-bytecode-vm-parser/
Okay, _now_ I'm done. Fixed a few parser errors and implemented a skew option (the `^` value) that will push the average value towards either 1 or the maximum of the dice. I like that once you get the parser up and running that it's easy to add stuff to it. I now am the official owner of a completely overkill dice running program.
For the example below, the skew is `2.0`. The random value is raised to the `1/skew` power before being multiplied by the number of sides of the die. If skew goes up, so do the results. If skew goes down, well, so do the results.
```
$ python main.py "^2 (2d6+2d8+12)[fire]+1d8[piercing]" | jq .
{
"results": {
"fire": 37,
"piercing": 7
}
}
```
In which I have Opinions about parsing and grammars - by Simon Tatham
https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/parsing/
who doesn't love a good #parser #differential #vuln in the morning? https://github.blog/security/sign-in-as-anyone-bypassing-saml-sso-authentication-with-parser-differentials/
#lispyGopherClimate #lisp #programming #podcast #live Wednesday 0UTC https://archives.anonradio.net/202503050000_screwtape.mp3
#climateCrisis #haiku and #risk #inequality #essay by @kentpitman
https://netsettlement.blogspot.com/2013/08/lien-times-for-startups.html
#libre #archive update from @hairylarry https://gamerplus.org/@hairylarry/114106383066762290
https://www.european-lisp-symposium.org/2025/index.html
#ELS2025 submissions extended to Sunday. #LaTeX #ACM #primer / past #proceedings
Notes from my first #language #parser #commonLisp #mcclim #chess
If there are guests, there are guests(?)
(Towards):
A #sidescrolling #textAdventure #game as the host of a Pratt Grammar #Parser:
https://lispy-gopher-show.itch.io/lispmoo2/devlog/870779/a-sidescrolling-game-as-a-pratt-parser
#itch #itch_io #gameDev #lisp #commonLisp #repl
Sharpsign lengthy and wandering. Sharpsign happy 2025
Basically, I was having trouble imagining parsing a grammar at all. So I imagined input tokens as a sidescroller level I could cdr-code speedrun passes of. And you know, when lisp people imagine things it happens in real life too.
I just released pyparsing 3.2.1 with a very cool addition to the railroad diagrams that pyparsing generates for its parsers - non-terminal diagram elements now link to their definitions elsewhere in the diagram! This is pretty handy when the diagram is for a complex parser, as in this demo of a parser/evaluator for time references like "3 weeks from today" or "0800 two days from now" or "in exactly twenty-four hours". #pyparsing #python #parser #railroaddiagram
Currently dallying with a simple embedded, statically typed scripting language. The magic is an extensible lexer and parser, with the hosting application able to do something like
VM_addCommand(vm, KEYWORD(“open”), KEYWORD(“file”), TYPE(STRING), KEYWORD(“as”), REFERENCE, END);
to allow something like
open file “foo.txt” as myFile
It’s obviously been done before, but it’s fun to play with. I haven’t done enough #compiler or #parser work lately.
Updated internal state handling of the https://thi.ng/parse parser generators & DSL to define parsers. Seeing a 1.2 - 1.6x speedup of parsing performance in example projects (see project readme for links), especially for larger inputs...
Over the past few days I've been working on extending & re-packaging the procedural text generation engine from one of the old examples into a new package and also just wrote/updated documentation for its various features:
- variable definitions, optionally with multiple value choices
- cyclic & recursive variable references/expansion
- variable assignments
- dynamic, indirect variable lookups (for context specific situations)
- optional preset & custom modifiers (i.e. pointfree/concatenative application of modifier sequences)
- controlled randomness during var expansion
The new package is called: https://thi.ng/proctext (6.5KB incl. all deps) The text format used relies on a simple parser grammar defined and processed via https://thi.ng/parse. The resulting document AST is then interpreted via https://thi.ng/defmulti
Please see readme for notes/examples, as well as the refactored example project below. The tool is very useful for complex source code generation, but also could be useful for bots, interactive fiction etc. The generator is stateful and variable state can be optionally retained/re-used over multiple invocations. Making all modifiers async is also providing a lot of flexibility (e.g. loading external data sources, generating secondary/expanded descriptions etc.)
Demo (incl. 5 examples and can be used as playground):
https://demo.thi.ng/umbrella/procedural-text/
JSON is probably the most used standard file format for storing and transmitting data on the Internet in recent times. It has a simple syntax with only four scalar data types and two composite data types. So, writing a parser for #JSON is a great exercise for learning the basics of parsing.
That's exactly what I did: I wrote a JSON #parser from scratch in #Haskell. Read my #blog post to learn about basics of parsing, nuances of the JSON syntax, and parser combinators and property-based #testing in Haskell: https://abhinavsarkar.net/posts/json-parsing-from-scratch-in-haskell/
Many people say that #Rust is very hard to #prototype with or to #refactor. This couldn't be further from the truth! It is the exact opposite!
Let me share with you one of the most profound experiences I had with #RustLang on a casual sunday - a thread 
I'm currently rewriting my #transpiler from #nom to #chumsky and until now everything has turned out great so far, until I've hit the following road block:
Implementing parsers by using #parser functions that have indirect #recursion.
1/11
"Sur l'inévitable" par paravaariar
Ce jeu à #parser est la traduction d'un jeu espagnol, développé avec fi.js (un moteur également espagnol en JavaScript qui a été adapté au français pour l'occasion).
Le jeu n'a pas de description donc je vous mets l'intro dans les prochains messages.
"Zigamus : Zombies au Vigamus" par marcovallarino
Hasard du tirage, c'est encore un jeu à #parser aujourd'hui. C'est la traduction d'un jeu italien qui a déjà eu le droit à une traduction anglaise. Réalisée avec #Inform6, elle est disponible avec ou sans illustrations.
[Description dans le post suivant parce qu'on atteint la limite de caractères]
If you're a creator, player, archivist or fan of #interactivefiction we welcome you to join the discussion at intfiction.org!