New Dialog extensions: preprocessing and pattern-matching

Preprocess.dg: allows authors to (effectively) mess with the player’s input before it’s tokenized, like I7’s “after reading a command” rules. Currently this is horribly inefficient and isn’t recommended for retro machines, but is at least functional.

Patterns.dg: A poor-man’s substitute for regular expressions, intended for use in preprocessing rules. A “pattern” is a list, consisting of:

  • Single characters or single digits, matched literally
  • The number 10, which matches any number of digits
  • Two-element lists; the first element must be a single character or digit, which is matched, and the second element will be substituted for it

For example, the pattern [10 [@. @$] 10 [k [@\s k]] h z replaces “92.46khz” with “92 $ 46 khz”.

Numberhack.dg: A quick-and-dirty workaround for a minor and obscure compiler bug. You’ll need it for Patterns.dg to work properly, and probably in no other situation ever.

3 Likes

And adding to this, Kinds-of-Value: a Dialog implementation of I7’s “composite kinds of value” (aka structs). You can pack and unpack them with (struct/kov $Struct has tag $Tag and contents $List), where the “tag” is a single value indicating what kind of struct it is.

The main reason this is useful is because structs, unlike normal lists, won’t be treated as multiple objects by the parser. If you (try [tune to [69 105]]), that’ll be interpreted as “tuning to 69 and 105”; if you instead tune to a struct containing those values, it’ll be interpreted as a single tuning action.

Could you tag these files with a version number (a git tag)? I can then update my dgt tool to pick them up from gitlab, like I already support github.

As in, tag certain commits with release numbers?

Yes, as per this:

I’d like to add :bitbucket as remote source. I think its best to link to a tagged version rather than a commit. Even just ‘v1’ is fine. The intent is to ensure that the build is reproducible, without having to directly copy dependencies into my project.

2 Likes

One issue there is that I keep all my extensions in a single repo, and I imagine others will too (that’s how Inform extensions are generally handled)—how should I indicate that there’s a new version of one extension but not of another, for example?

You’ve probably already considered this, but how would you feel about having some metadata in comments at the top of the file? That way each extension could provide its own semver number independently of the others.

2 Likes