A good concrete example here is a compiler project I was involved in where our first implementation had AST nodes which used a type parameter to represent their expression types: in effect, this made it impossible to produce a syntax tree with a type error, because if we attempted this, our compiler itself wouldn't compile. This approach did catch a few bugs as we were first writing the compiler! It also made many optimization passes into labyrinthine messes whenever they didn't strictly adhere to the typing discipline that we wanted: masses of casts and lots of work attempting to appease the compiler for what should have been simple rewrites. In that project, we eventually removed the type parameter from the AST
which also seems to conflict with this:
Using data structures indexed by compiler phase is a good example of a “fancy type-level feature” that I've found remarkably useful in the past.
Both of these sound like the "AST typing problem" - https://news.ycombinator.com/item?id=37114976
which I admit I'm a bit skeptical of, because the problem is type safety, and not the compiler's actual algorithm or actual performance.
But I guess the first one is for syntax trees, and the "trees that grow" paper (linked in the article) is for back end passes? Does that change the problem so much?
I'm not experienced with back end passes for compilers, but I personally don't see the problem of using either a Map<AST, ExtraInfo> or a nullable field.
I just hacked on a toy codebase that had the Expr<void> and Expr<T> type safe solution, and it's interesting. But my first impression is that it causes more allocations and makes the code a bit longer.
---
I guess another way to justify the Map is that it's like math -- a "typing relation" is an association from expr to type, so a map or multi-map seems natural to model it.
data Term t where
Num :: Integer -> Term Integer
Bool :: Integer -> Term Integer
Add :: Term Integer -> Term Integer -> Term Integer
IsZero :: Term Integer -> Term Bool
IfThenElse :: Term Bool -> Term a -> Term a -> Term a
With this AST, you can express well-typed programs like `Add (Num 2) (Num 3)`, but the Haskell type system will stop if you express an incorrectly-typed program like `Add (Num 2) (Bool False)`.The "Trees That Grow" paper, on the other hand, is about reusing the same AST but gradually adding more information to the nodes as you progress through the compiler. For example, you might want to start with variable names being raw strings (so that a term corresponding to `lambda x: lambda x: x` looks like `Lam "x" (Lam "x" (Var "x"))`) but eventually replace them with unique symbols so that shadowed names are non-identical (so that under the hood it looks more like `Lam 1 (Lam 2 (Var 2))`, although in practice you'd want to keep the old name around somewhere for debugging.)
One way to accomplish this is to introduce an explicit type-level notion of compiler phases, give your terms a type parameter which corresponds to the phase, and use the phase to choose different representations for the same nodes:
data CompilerPhase = Parsed | Resolved
data Expr (phase :: CompilerPhase)
= Lam (Name phase) (Expr phase)
| App (Expr phase) (Expr phase)
| Var (Name phase)
type family Name (t :: CompilerPhase) :: *
type instance Name Parsed = String
type instance Name Resolved = Int
Using this example, an `Expr Parsed` will contain variables that are just strings, while an `Expr Resolved` will contain variables that are integers, and you can write a pass `resolve :: Expr Parsed -> Expr Resolved` which just modifies the AST. (This is a toy example: in a real compiler, you'd probably want to create a new type for resolved variables that still keeps a copy of the name around and maybe some location information that points to the place the variable was introduced.)(Or perhaps it does and this is just some Ruby-ism I'm not exposed to)
def foo(kwargs = {}, frob:)
kwargs
end
def foo(kwargs = {})
kwargs
end
foo({k: 1}) # ok: passing hash argument
foo(k: 1) # ok: keywords coerced to hash
One of the strongest arguments for avoiding this sugar is that it makes the code more brittle in the face of future changes. In particular, in the example above, if we add a new keyword argument to `foo`, then any call which omitted the curly braces will break, while calls which used them will keep working fine: # added a new keyword arg here
def foo(kwargs = {}, frob: false)
kwargs
end
foo({k: 1}) # still ok: `frob` defaults to false
foo(k: 1) # ArgumentError: no keyword: :k
This is touched on in the blog post describing the extensive changes made to keywords in Ruby 3: https://www.ruby-lang.org/en/news/2019/12/12/separation-of-p...I like the idea of the OSR systems with small rulesets. So I'll check The Black Hack first. Do you know about any systems like this one that have been published under the Creative Commons license?
If you're interesting in something very D&D-like, there's obviously Pathfinder 2E[1], which builds on the same D&D skeleton but has a much sharper and cleaner approach to grid-based tactical combat. However, I'd also suggest looking at some of the games in the OSR ("Old School Renaissance") space. Games like The Black Hack[2] or Maze Rats[3] provide a much smaller set of rules which are easy to adapt to other adventures: the goal is that you can take adventure modules for effectively any existing D&D-like game—including both present and past versions of D&D—and run them with little overhead.
Something pretty different mechanically but which is quite compelling in that space is Torchbearer[4], which is based on the underlying Burning Wheel[5] system but made significantly simpler (and shares a lot of those simplifications with Mouse Guard[6] except it's, well, not about sword-wielding mice.) Torchbearer is a great dungeon-crawl-focused system that can really capture grit and difficulty in a way that's a lot of fun, but it's also the kind of game where you can get a total party kill not just by a dragon but also by running out of food and torches, so expect a grimy tough game out of it!
If you're looking for something even further afield, I'd suggest taking a peek at Dungeon World[7], which borrows the core mechanics from indie darling Apocalypse World[8] but applies them to a traditional D&D milieu: that said, I'd actually start with Homebrew World[9], which streamlines and clarifies a lot of the rules, but it might require Dungeon World itself to get a handle on how to run the game. Games inspired by Apocalypse World—sometimes called Powered by the Apocalypse games—definitely play a bit differently—they tend to be a bit more "zoomed-out", e.g. combat being resolved in a fewer high-level rolls rather than playing out a full sequence of six-second slices like D&D—and they aren't to everyone's liking, but I think they're worth trying.
I'm also going to plug my personal favorite tabletop game, Blades in the Dark[10], which is not a traditional fantasy game (although people have adapted the the rules to more traditional fantasy, c.f. Raiders in the Dark[11]) but which I think is super compelling. It's about criminals in a haunted Victorian-ish setting doing odd jobs, and builds a system that's top-of-its-class for doing that, including mechanical support for heist-movie-style flashbacks and a lot of systems designed to let you do risky moves and narrowly avoid failure from them. Some of my absolute favorite TTRPG moments have been in Blades games.
Any of that sound interesting? Want other examples or directions?
[1]: https://paizo.com/pathfinder [2]: https://www.drivethrurpg.com/product/255088/The-Black-Hack-S... with the open content collected at https://the-black-hack.jehaisleprintemps.net/ [3]: https://www.drivethrurpg.com/product/197158/Maze-Rats [4]: https://www.burningwheel.com/torchbearer-2e-core-set/ [5]: https://www.burningwheel.com/burning-wheel/ [6]: https://www.mouseguard.net/book/role-playing-game/ [7]: https://dungeon-world.com/ [8]: http://apocalypse-world.com/ [9]: https://spoutinglore.blogspot.com/2019/05/homebrew-world-v15... [10]: https://bladesinthedark.com/greetings-scoundrel [11]: https://smallcoolgames.itch.io/raiders-in-the-dark
Apart from the core design, D&D is also pretty middling as a product. Being a DM for D&D is hard—a fair bit harder than running many other tabletop games—and the book are at best a so-so resource: there's a lot of extra prep and careful balance that rests on the DM's shoulders, and doing it right means either falling back part-and-parcel on adventure modules or doing a lot of careful tuning and reading forums and Reddit threads. In an ideal world, the core books would include everything you need to know, but in practice the best DM advice is outside the core books (and sometimes even contradicts the books themselves!) Many other games don't have this problem.
To be clear, I don't think D&D is a bad game, but plenty of other games out there have clearer core designs, better presentations, easier-to-grasp rules, and overall more polish.
Since then, aside from some interesting bits of work that didn't actually make shipping games easier, the engine really languished. My understanding is that a big part of the reason the engine was removed was that it made work on other parts of Blender more difficult, and that dispensing with the (little-used) engine in favor of the (increasingly popular) modeling tool was clearly a net benefit to being able to develop Blender, especially since the mantle of "open source game engine" had been taken up by other competent projects like Godot.
So yes, they may have at some point aspired to becoming a "mainstream game engine", but there's more to that effort than just aspirations and demos. (And at the same time, the fact that the BGE faltered doesn't mean that other open source game engine efforts would necessarily face the same fate.)
It's probably also worth saying that people have forked the game engine and you can still use it: the forked version is called UPBGE, and there are people out there trying to make it work. By and large, though, the Blender project seems to point people at projects like Godot, with the idea that a focused game engine is probably better suited to modern games than something that strapped a game engine onto a piece of modeling software.