If you haven’t heard of glish before, check out the post What is Glish?
This is the first in a series I’ll be publishing on my experiences creating a new programming language. I’ve been working on Glish since late 2015. It’s gone through several complete rewrites as I’ve learned more about how the eventual programming language should look, but this epoch is trending in a direction that might be workable. I recently started writing notes about my progress to help coalesce my thoughts and direct my development efforts. I typically do this at the end of any day I make a commit to the repo, so this is just a dump of those notes. As time moves on, I might add more cohesion to these updates.
First implementation of rulebooks done today. There are lots of problems:
- no way to query the outcome of a rulebook
- no named outcomes
- rulebooks cannot have a basis
- rulebooks cannot produce a value
- the implementation is a massive pile of hand-written AST nodes and code literals
- there is very little testing
I like the implementation where it creates a separate program to merge in, but there has to be an easier way to create the program.
Inform’s rulebooks which produce values are allowed to “succeed producing value”, “fail” and “make no decision”. Additionally, rulebooks that “don’t produce values” can set named outcomes and produce any of those outcomes as well as “make no decision”.
Rulebooks need quite a bit of other work before I can really continue on them:
- enumerated types are going to form the basis for named outcomes
- loop constructs are going to be key to removing the code literals from the implementation
Was able to get a basic kind of either-or property implemented today. There are obviously problems.
now X is Y always makes a new instance, it doesn’t understand asserting something about an existing value. I need to modify
analyzeAssertion to somehow detect whether or not to allocate a new variable versus modify the properties on an existing one, including asserting new facts about a global variable.
Conditions can only check a single adjective because they are matching phrases rather than descriptions. I should modify the description matcher to take an “expected kind” to allow descriptions which don’t include a kind.
All my properties are all checked with
===, so I need to make sure that default values get set properly.
I also noticed that the “variable initialized somewhere else” error doesn’t show its position correctly in the error messsage.
I think the next course of action should be fixing up the first two problems here, then moving on to adjectives describing value properties.
Types for phrases of one arg and rulebooks are implemented fairly well now. Here are my thoughts on my next steps:
Enumerated properties are necessary for named rulebook outcomes, and named rulebook outcomes will require some thought as to the phrasing and structure they permit. Enumerated properties are also holding up my implementation of Bohnanza, because I use them for turn phases.
My Nim example doesn’t work because
require aren’t exposed to the running code. I looked into how
require, and it ends up doing it through a require hook using pirates. This would require a bit of a refactor in the compiler, but shouldn’t be too hard. I think I should probably focus on the entry points into glish programs before going on too much further.
The only other problem I can see right now is around descriptions. I want to be able to say “taking the actor” and have it match taking actions where the actor is the object.
I think my list of priorities should look like:
- Implement this “taking the actor” self-referential description type.
- Think about how glish programs will be run.