lisp VS tailspin-v0

I've been curious about https://github.com/ezekiiel/lust but I don't know its status as a project

Since last month I've been working on garbage collection and string handling in my Lisp compiler. I've found writing the garbage collector to be hard but strings are fun :)

I just added variable-arity functions to my lisp which compiles to Cranelift. I was blocked for a while trying to work out how to convince Cranelift to put arguments on the stack but eventually gave up and I now heap allocate a location for function arguments. It's not great for performance but it feels great to have finally finished it!

I’ve been carrying on working on compiling my lisp this month. It’s been a fun couple weeks because I’ve finally gotten to the fun stuff like higher order functions, closures, and adding the ability to call into libc.

I eventually tend to do all days in Tailspin. The ones I have done so far are in directories ending in "tt" (the others are in Pyret, just to get a feel for it) https://github.com/tobega/aoc2023/tree/main

As a general tip, it is often helpful to first try to think of how you would like to represent the data in your program. Then you need to parse the data into that structure. I'd recommend you to look at a PEG-parser, for example. Or if you like, look at my Tailspin programming language which has a very visual parser syntax and also very visual ways of creating data structures (if that should happen to be your mental affinity). Look at my day1 for example. Or if you're more mathematical, maybe a functional language (I also did day1 in Pyret)

My Tailspin language is based on processing streams of values, you might want to look at it https://github.com/tobega/tailspin-v0

Many people had trouble with the day 7 problem. Paradoxically, good developers probably had more trouble. Here some of the difficulties are explained and implementations are provided in imperative, functional and OO styles, written in the Tailspin programming language.

I test almost entirely from my language, that way the tests are independent of the implementation. Currently the tests are implemented in java because that fits the interpreter implementation https://github.com/tobega/tailspin-v0/tree/master/test/tailspin/samples

Finished off the implementation of typed and offset array indices in Tailspin

I ended up enabling left recursion in Tailspin's composer (parser) syntax. Much cleaner calculator example now.

I think it's possible that Tailspin might be suitable for you.

I think gradual typing is definitely something worth exploring more. I thought it was a shame when Dart abandoned that path. Have you seen Shen ? I guess my small offering, Tailspin, is currently evolving to gradual typing as well.