Perhaps we could compromise by bringing back the old Byzantine O-U ligature and call it “colȣr”. And then compromise a second time, the way various Native American languages with the letter ȣ do nowadays, and call it “col8r”. That should satisfy everyone.
1 Like
As a brit, I say just use color. I’m used to that from using CSS, so it doesn’t seem odd. And if one thing starts using UK spelling as a variant, I’m going to expect other things to do the same.
5 Likes
To pick up the conversation from Github, since this is where everyone else is hanging out… my general bias is to leave things out unless there are strong reasons for it to be in. (This balances the other natural maintainer’s bias to pack your library full of useful things, each of which are useful individually but can be overwhelming in aggregate. This one’s hard for a maintainer to spot, since it gets added bit by bit but hits new users all at once.) One of the nice characteristics of Dialog is that compared to other systems the library is small and straightforward; this feels like one of the core design principles of the language to me and I’d hate to lose it.
Obviously this is, like, one tiny predicate and not a big deal! But that’s the motive for the vote.
I’m kind of split on the feature-testing predicates, though in that case there’s certainly no alternative to them if they’re not supported natively. Do you have an example of where the non-text-alignment predicates are needed? (And better than designing your way around the problem, as you suggest?) One risk also is that the Z-machine interpreter can lie about these things… I feel like I’ve seen some examples of that in the wild, though none come to mind. (Except my own Z-machine code in earlier versions, I guess… 
)
2 Likes
Color testing is for things like the footnotes and link keywords in Wise-Woman’s Dog. If you play it on Z-machine (or Å-machine without links), you get this box right before the first command prompt:
(A couple turns later, it uses green for footnotes as well.)
Currently, it assumes that every interpreter supports color, and users have to specifically go into the menu and flip the switch if they want [brackets] instead. It would be nice if the interpreter could just tell me outright “I have no colors, default to using brackets”.
I haven’t had a need for the “bold and italics” one myself, but I know some authors like to put object names in bold or italics instead of color. Even if the interpreter sometimes lies, it can provide a better default than assuming everyone will be able to distinguish bold and italics when you use it for a puzzle.
1 Like
well, since early inform, the usage of british spelling (albeit mandatory in pre-7 inform) should be acceptable in an IF language
Åsman is finnish, an European country, and in EU the english spelling IS the british one.
best solution I can suggest: US spelling as synonym of UK spelling, as syntactic sugar (on this side of the atlantic, british spelling IS English language, and Åsman is European, so Dialog’s “native” spelling is the UK one)
Beest regards from Italy,
dott. Piergiorgio.
The obvious solution: standardize on Canadian English as a compromise. 
1 Like
As in “Tim Horton Hears a Hue”?
4 Likes
Neither I or Linus are finnish. We are both swedish. Our countries have been seperated since 1814.
2 Likes
Clearly the solution is to drop support for color/colour altogether. No fancy styles or anything eitther - just plain (monospaced) text on a plain background. 
The nice thing about how builtins are implemented in Dialog, there doesn’t have to be one “native” spelling: there’s a big data structure mapping predicate names to internal enum codes, so there can be two names for the same enum code as easily as one. By the time it gets to the AST level, there’s no distinction at all.
Has there been a discussion about the localization of all the messages ?
I’ve seen many improvement implemented in the standard lib and elsewhere, and it’s starting to diverge largely from the french version of the stdlib for dialog (named cadratin and made by @Natrium729 ), and it’s starting to become difficult to follow (in the current state, you have to both report changes + do translation), it’d be cool if there was a more easy way to update the localization over time.
1 Like
Actually my translation is not actually a direct translation of the original stdlib (hence a different name instead of, say, stdlib-fr) because it adds or changes some features. And I chose to separate the French from it so that it could be in English too.
I believe Linus didn’t want have a way to localise messages or whatnot, because for him a translation would change so many things that you would just fork the lib and rewrite everything yourself.
For example, I think he said that the action names would be translated to French, this kind of thing. I don’t really agree and think the action names should stay in English, otherwise it’s kind of a pain to use extensions and so on that assume action names in English (you would have to translate them too.)
I don’t know what is the opinion of other people who tranlated the standard library.
1 Like
Yeah, I’m all in favor of localization, but I unfortunately don’t know enough French (for example) to meaningfully contribute to that project. One of the benefits of the standard library being entirely normal Dialog code is that translators can change absolutely anything (instead of just replacing pre-selected strings), but that also means that work ends up being mostly the translators’ responsibility.
We do document all the standard library changes in the README, and looking at the git history should help pick out exactly what changed between versions.
So if I want to do the Photopia effect, but also support the light/dark mode toggle (e.g. the “red” area would either be red-on-black, or black/brown-on-pastel-red, depending on selected mode), is there a recommended way to do that under the new system?
(Turns out this isn’t entirely hypothetical…)
Yep! Instead of setting color and background-color, set --day-fg, --day-bg, --night-fg, and --night-bg in the appropriate combinations. (That won’t affect the UI, by default, but you can mess with --ui-* as well if you want.)
1 Like
Turns out the shiny new style system I mentioned above didn’t quite work. Once this PR is merged, it should. Oops!
Per this poll, SHOUT is going away. SHOUT TO X is now a synonym for CALL X. CALL ME has a special response: “Why call when you’re already right here?”
As part of this, I had to regenerate one of the manual’s diagrams, so I’m leaving my GraphViz code in the same directory so that future maintainers can edit it.
3 Likes
Currently, fonts will be embedded into the web page if they’re defined anywhere in the aastory file, without requiring an explicit (embed resource $). This is a bit inconsistent design-wise, but it ensures that the fonts can be loaded alongside the rest of the web page, before executing any Dialog code.
How do people feel about this inconsistency? Should fonts require an (embed resource $), even though that means the fonts won’t start loading until the Dialog code starts running?
- Embed fonts when the page loads, without Dialog explicitly asking for them, so they’re available right away
- Require an explicit (embed resource $) to load the font, but it can’t be used until some time after that
0
voters
That seems like a pretty strong consensus! One more question as we work toward Å-machine 1.0.0:
All versions of the Å-machine record an options string for each resource (graphics, sounds, fonts, etc). The format doesn’t specify anything about this string; before 1a/01, Dialog always emitted an empty string, and no interpreters ever cared about it.
For 1a/01, I wanted to support sound, so I updated Dialog to let users supply this string (arbitrary UTF-8 that can contain any characters except ;, which is the end marker), and I made the interpreter look for /\bloop\b/ and /\bchannel (\S+)/ in that string to set properties for the sound. That worked fine for Wise-Woman’s Dog, but the regex parsing is not very scaleable.
Now, for the font support, I needed a way to let people specify arbitrary CSS properties, so I made the interpreter split the string on /\s*,\s*/ (that is, commas with arbitrary amounts of optional whitespace on either side) and store the results as an array. This makes the parsing much easier for both fonts and sounds.
But, version 1.0.0 of the Å-machine is the best time to actually specify these things, before people write a bunch of code relying on the old behavior. So I’m contemplating two possible ways forward:
Path 1: Specify only that an option string is a list of options separated by commas (with optional whitespace around the commas). The internal format of each option is not specified, and the interpreter can choose to parse the options differently for different types of resources, or even different properties. This path imposes the fewest requirements on how options should look for the future, but it also ties our hands for any future specification, because interpreters might parse those options in all sorts of different ways.
Path 2: Specify that an option string is a list of options separated by commas (with optional whitespace around the commas), and that the format of each option is either a key and value separated by a colon (again with optional whitespace), or a key not containing a colon. Keys need not be unique. (For the JavaScript interpreter, keys with no values will map to “true”, and keys appearing multiple times will have their values consolidated into a list.) This path constrains the format of options quite a lot, but it means that authors can rely on that format to be stable and not change on them unexpectedly.
Personally, I favor the second path. I think specifying now will save us a lot of headache in the future, and I can’t think of many things that this format can’t cover (basically just options containing any of , : ;). But before I lock anything down, I want to solicit feedback first.
So, what do you all think? Please comment and let me know!
- Leave the structure of options unspecified and let interpreters do whatever they want.
- Specify the structure of options so that interpreters will be consistent.
- I have objections to both of these!
0
voters
I’m always in favour of structure, but I wonder if this is the right structure… Left to myself I’d consider sort of s-expression syntax – lists which either consist of single options or lists where the option is the head, and the values are the tail. That’s moderately flexible, but also easy to parse, and also allows for option values to be lists and so on.