Dialog Wishlist

Authoring Dialog
1

Dialog doesn’t seem to be under active development any longer, but it is open-source, and I’m tentatively poking through the compiler code to try to get a sense of how it works. It is unfortunately very sparsely-commented, but I’m trying to gauge which changes would be easy, difficult, or nigh-impossible to make.

From the creator Linus Åkesson’s comments, he’s considered:

  • Removing the inline style predicates, replacing them entirely with spans
  • Broadening the limits on numbers, and allowing negative numbers
  • Adding a built-in predicate for splitting unrecognized words into a recognized prefix and an unrecognized suffix, which would let the library handle removable endings
  • Making numbers be a subtype of words

As for my personal wish list:

  • Supporting more styling on Z-machine, such as text and background color
  • Allowing more than 128 non-ASCII characters in I/O
  • Support for a 32-bit backend like Glulx, which would effectively remove memory limits

But what about the rest of y’all? Are there particular issues you’ve run into with Dialog that you hope could eventually be changed?

8 Likes
2

Out of all of these, the color support on Z-machine seems the most viable for someone inexperienced with the codebase, so I’ll probably try that first to see how horribly things break. I have a div class for meta messages and a div class for tutorial messages in my IFComp entry, which appear in nice little green and blue boxes on web, but have no way to distinguish them on Z-machine; green and blue text might be garish, but it would at least offer some distinction.

1 Like
3

…what is happening in the Dialog space? :open_mouth:

2 Likes
4

Incredible things!

1 Like
5

Yeah, all the current Dialog backends are 16-bit systems, which means there’s only 216 different values to represent numbers, objects, dictionary words, pointers into the heap…

So rather than require the user or the compiler to keep track of types, one of the design decisions was to restrict all arithmetic to 14-bit unsigned integers. Why unsigned instead of signed? Because 214 > 10,000 which means you can do four-digit passcodes and such, and that was considered more important for parser IF than negative numbers.

2 Likes
6

(To the original question: I think you were the one who suggested having the web player use normal link elements instead of special spans, and that made me wish that it were possible to emit more element types for at least the web, like eg. unordered lists. But I don’t have any very concrete proposal for how this might look…)

2 Likes
7

Agreed there! It would also be nice if the style classes would let me specify ARIA roles, so that (span @italic) can be given the emphasis role and so on.

Currently I’ve got a sort of hacky workaround for unordered lists (just a series of divs with a bunch of CSS around them) but it’s not ideal. Unfortunately I don’t expect that to change since part of the goal of Dialog is to be backend-agnostic.

8

I remember it being very difficult to have a global number variable and increment it or decrement it. When I did impossible stairs, I tracked the decade you were in, and getting it to go up by 1 or comparing it to stuff meant I always had to toss it into a temporary variable, like:

(narrate leaving * #up)
	(TimeAge $CurrentTime)
	($CurrentTime plus 1 into $Temp)
	You climb up the stairs.
	(if) ($CurrentTime = 1)(then)
		They seem to get smaller as you get higher. Or have you gotten taller?
	(else)
		For some reason you feel more tired the higher you get. This part of the house looks different, too.
	(endif)
	(now) (TimeAge $Temp)
	(tick)

TimeAge is a global variable, CurrentTime is local.

Here’s another example:

(descr *)
	(TimeAge $CurrentTime)
	(if) ($CurrentTime = 1)(then)
		Moving into this new house has been a big adventure for a little kid like you.
	(elseif) ($CurrentTime = 2)(then)
		Visiting from college has done wonders for you. Everyone around you likes you, your laundry's done, and you're happy.
	(elseif) ($CurrentTime = 3)(then)
		You're still feeling a bit frazzled from the hurricane and helping your dad pack for his big move, but otherwise you're doing fine.
	(elseif) ($CurrentTime = 4)(then)
		You've felt much calmer now that you're contemplating retirement. It'll be nice to have a break from work.
	(else)
		It's harder to get around these days, especially bending down to grab things. It's one reason you've had to sell the house. But it's had a good run, and, so far, so have you.
	(endif)

It’s possible that there are already easier ways to do this, in which case I guess I’d wish for better documentation.

1 Like
9

That’s a fair point, though it feels similar to the kind of compromise that Dialog already makes: supporting CSS but only recognizing a hardcoded subset of properties when exporting to the Z-machine, for example. (But definitely not familiar enough with the code to have an informed opinion!)

2 Likes
10

No, that’s about the best way to do it. For the second example, you could break it out into multiple rules:

(descr *)
    (timeage $Current)
    (describe * at age $Current)

(describe * at age 1)
    Moving into this new house...
2 Likes
11

The idea there is that Dialog, as a language, allows you to specify whatever CSS you like, and it’s up to the backend how much of that it recognizes. So I could imagine it potentially adding a new (unordered list) syntax or something, which could either be printed with a <ul> or with normal line breaks.

12

On further inspection, this seems like a relatively easy change, since it only affects the compiler, not any of the runtime representations. Basically just requires adding an extra field to the compiler data structure for a style class.

This one’s going to be a pain. It’s technically doable but it requires modifying the Å-machine specification. I think the best way to do it would be to modify the printing code so that it can output arbitrary unicode characters, but can’t use them in input or dictionary words. Alternately, there are 255 reserved values in the Å-machine’s memory definition that could be allocated to more characters, but that seems less wise.

Glulx output seems very feasible, actually, just incredibly tedious to implement. It uses a very similar architecture to the Z-machine, but all the runtime support would need to be reimplemented in Glulx assembly.

I’m going to try implementing something like this in library code for starters, and then see about speeding it up with an assembly implementation.

Pretty much trivial, but somehow I don’t think people would want to download and build my fork of Dialog if its only selling point is taking out features…

2 Likes
13

i’d chew my arm off for glulx output. although that does seem like the least forthcoming.

1 Like
14

I think it’s a lot more doable with my limited skillset than anything on Linus’s wishlist! Just extremely time-consuming.

The important files for this are backend_z.c and runtime_z.c. The former converts from the compiler’s internal representation into Z-machine assembly, which it mostly does by calling special routines (what Inform 6 coders would call “veneer”) for anything nontrivial. The latter contains all these routines, looking like this:

	{
		R_SET_PARENT,
		2,
			// 0 (param): object (tagged reference)
			// 1 (param): new parent (tagged reference)
		(struct zinstr []) {
			{Z_CALL2S, {ROUTINE(R_DEREF_OBJ_FORCE), VALUE(REG_LOCAL+0)}, REG_LOCAL+0},
			{Z_CALL2S, {ROUTINE(R_DEREF_OBJ_FORCE), VALUE(REG_LOCAL+1)}, REG_LOCAL+1},
			{Z_INSERT_OBJ, {VALUE(REG_LOCAL+0), VALUE(REG_LOCAL+1)}},
			{Z_RFALSE},
			{Z_END},
		}
	},

Most of the changes to backend_z.c would be straightforward enough. Just change the Z-machine assembly it’s outputting to Glulx assembly. (Well, technically it’s binary machine code rather than assembly, but the structs are set up so you’re basically writing assembly.)

The hard parts would be changing the handling of text and dictionary words, since the Z-machine defines the structures of those, and Glulx doesn’t really, so you can do it in more flexible ways (e.g. allowing arbitrarily long words).

The changes to runtime_z.c would be less technically challenging but more tedious. 150 routines or so have to be rewritten in Glulx assembly, to best take advantage of the format’s strengths. This is a place where an experienced I6 programmer would be invaluable.

I can definitely see this happening, but also I’m a PhD candidate working on a thesis and other research on the side, so I don’t foresee myself having the time to do this on my own any time soon. If people were interested, I could try to coordinate a project, but we’d need people with experience with at least two of C, the Z-machine, and Glulx.

4 Likes
15

I don’t know if I’d have time to work on it directly, but I’m available to consult on VM and assembly matters.

I don’t think there’s a Dialog Github repository is there? I recommend setting one up. Perhaps even an organisation, so that community libraries can also be hosted.

When I’ve looked at Dialog before, my impression was that a lot of its limitations could be worked around if there was a way to have inline assembly. I expect that the reason it hasn’t been allowed is to allow you to compile to either Z-Code or Å-Code, but for those who need it, being restricted to one output platform would be acceptable.

3 Likes
16

Although this has a minimal impact on the actual structure of language, I want an Amiga interpreter. Despite the bigger opcodes on the 68000, I suspect a 68k terp could be made to run almost as efficiently as on the 6510.

Dialog uses IFF (a format popularized by the Amiga) to store data (particularly images files), and Dialog has held off on supporting image display tags. I don’t think this is a coincidence: reading between the lines, it does sound as if Linus has planned on eventually introducing graphics, possibly (probably?) using the IFF format.

Dialog should allow for a highly efficient Amiga interpreter, one capable of displaying Amiga images with native bit depth (16, 32, 64, or potentially thousands of colors, optionally with animated palettes a la Jim Sachs – for those of us who think Magnetic Scrolls were on the right track).

JimSachs_20000LeaguesUnderTheSea_Sunset

3 Likes
17

I’m with @Dannii and think a Github repository would be a good start for organizing issues and getting a community effort started. It would be nice to get @lft input but he don’t seems to respond to Dialog comments anymore…

3 Likes
19

Absolutely beyond my skills, alas.

What are you looking for with this that (embed resource $) doesn’t do?

Sounds like a good idea! Unfortunately I’ve never created an organization before.

A way to insert some raw bytes into a routine would be possible, if distinctly inelegant. My main concern would be heading off more elegant ways to handle things at a language level.

But some sort of “language extension” feature, where you provide a binary file of raw Z-code or Å-code and a signature for it, and can then query it like any other predicate…I think that’s got potential now that the language is no longer under active development.

1 Like
20

well resurfaced, Henrik !

As you see, your work goes on… so I agree on opening a Github repo and continue onwards ! let’s start with collating the bugs & most interesting feature request into a list to be fed to github’s issue tracker…

oh, a word for Bjorn: on animated IFF, one should not forget that often 16-bit artists of the 80s and 90s takes in account the limits and peculiarities of CRT monitors, and animated-palette dithering and thin lines of nearby colour actually exploits the limits of CRT technology giving more photorealism thanks to the blurring and inherent imprecision of phospors and cathode beam… so, the Amiga IFF you posted as all the aura of being much better when rendered with phosphors than with LED and LCD…

Best regards from Italy,
dott. Piergiorgio.

2 Likes
21

Things I can think of right now:

  • Escape sequences to output Unicode characters. Granted, you can type them directly in the source, but it’s not great for those who are invisible (e.g. non-breaking space).
  • Not a priority, but some kind of verbatim mode like the <pre> HTML tag could be nice. Right now it’s a pain to have ASCII art, you have to write a lot of (space $) and (line) otherwise the spaces are collapsed, and you have to escape several characters with a backslash.

I also have a list of bugs and weird behaviour somewhere that I have to find back.

I agree we should setup a repository somewhere. Ideally we should also get the blessing from Linus. If we stray too far from his “vision” (like adding inline assembly), maybe we should find a new name for our potential fork.

1 Like