~sjm

Manchester, UK

https://sjm.codes

Trackers

~sjm/role-up

Last active 3 years ago

~sjm/well-kard

Last active 3 years ago

~sjm/nesktop-experiments

Last active 4 years ago

~sjm/content-addressable-notebooks

Last active 4 years ago

~sjm/lonely

Last active 4 years ago

~sjm/sri

Last active 4 years ago

#10 consider `jq` as a source of edit/update syntax inspiration 3 years ago

Ticket created by ~sjm on ~sjm/role-up

#9 would it be better to build the repl first and simply back it with a full JSON representation? 3 years ago

Ticket created by ~sjm on ~sjm/role-up

This would avoid the need to design syntax and build a parser upfront. If I still felt the format was valuable after the repl was built, then I could still build the language out - but if the JSON covered the use case and tooling avoided the need for ever editing the file directly then I could stick with JSON or use a SQLite backend, or some other backing format.

The JSON representation would still be a series of events, of course. Think

[
  { action: "set property", property: "name", value: "jim" },
  { action: "set property", property: "xp", value: 8 },
  { action: "update property", property: "xp", update: { type: "add", value: 1 } }
]

This still requires some smaller amount of parsing within the repl, but could start with the CLI first to skip over that, then we'd already have a library for making those changes to a backing store and generating output, and could build up over time. The repl may be a good route for making the language both usable step by step while being useful and without having to start whole-hog.

#8 convert to & from JSON? 3 years ago

Ticket created by ~sjm on ~sjm/role-up

this could be useful. It may only capture static states, though, rather than the full series of events?

I should be careful to not just reinvent JSON in all this, the focus needs to be on 'append-only, edit while playing'.

although a repl which modified a JSON file in order to create the character sheet may remove much of the need for a parser, etc? Worth considering

#7 add the ability to add a property that is omitted from the output 3 years ago

Ticket created by ~sjm on ~sjm/role-up

This would be useful for properties that only affect other properties.

#6 consider lists and 'objects' 3 years ago

Ticket created by ~sjm on ~sjm/role-up

I'm not sure that we need objects, but lists could be very useful. Rather than mimicking JSON it could be good to have a modifier on the property, something like

myList :+ item one
myList :+ item two

which would, in json terms, be

{
   myList: [ "item one", "item two"]
}

#4 Add comments 3 years ago

on ~sjm/role-up

REPORTED RESOLVED FIXED

#4 Add comments 3 years ago

~sjm assigned ~sjm to #4 on ~sjm/role-up

#5 Design 'documentation'/'story' comments 3 years ago

Ticket created by ~sjm on ~sjm/role-up

These comments should attach to other nodes so that they can be preserved in the AST and produced by the compiler later.

For example, adding a comment to a property will always apply to it and display it when that property is queried for an explanation. These comments are a kind of documentation, but they could also be storytelling. They may be attached to an event. There may even be a 'storytelling mode' which walks through the changes a character has had using these comments.

I'm not sure how these should look yet, so they need designing.

#4 Add comments 3 years ago

Ticket created by ~sjm on ~sjm/role-up

single line comments using --, multi-line comments using {- -}.

#3 Add events which affect properties 3 years ago

Ticket created by ~sjm on ~sjm/role-up

I need to have a think about the syntax here, but roughly speaking:

str: 8

(str: + 1)

should result in

str: 9