Inform 7 is a very different language from other programming languages. Historically it was developed to be domain-specific and usable by non-programmers.
This is wonderful news! Inform has been one of the most interesting programming languages for a long time, but it was always a fatal flaw that it was unfree. I'm so happy to hear that problem has finally been solved!
Inform 6 and the Inform6 English library were free but not if7.
You could code Z-Machine games freely (as in freedom) with an OOP language 1000 times simpler than Python and the English library handling everything for you.
Sure but Inform 6 and Inform 7 are essentially entirely unrelated thought processes; like, I definitely consider Inform 7 to be one of the most fascinating--if, though, at least to my sensibilities: "ridiculous"--programming languages ever designed (and actually used), while Inform 6... is a programming language, sure ;P.
The name made me think it was yet another one of those proprietary DBMSs which came with their own integrated programming language and was relatively popular from the 80s through the 2000s, like the dBase family.
I'm happy and excited to see this happen, I have used Inform 6 in Plan 9 for interactive fiction development for years now, and with Inform 7 becoming open, I'm hoping the core compilation pipeline can be ported, reading source code for games like Counterfeit Monkey by Emily Short is quite amazing.
We need more libre IF games written in Inform6/7 too. If so, a lot of games could be translated and enhanced from Spanish to English back and forth.
And viceversa. I can read Anchorhead with patience, but in Spanish would be amazing (and in my native language the prose can be obviously as good as in English).
Also, Anchorhead had ben expanded and the author got a nice chunk of sales
with that release. Why should the free version stay as freeware? People would have that game in any Linux/BSDdistro and still pay for the images-enhanced one as Lovecraft themes with proper media it's a huge boost for inmersion.
> For Inform that human-readable format is a website, rather than a printed book
I dunno. I think hypertext, while well-suited to model traditional non-literate programs, really punts on the promise of literate programming. Even ignoring that—
> "Once The Historian is done, the instructions are passed to Instruction::read, which parses them more fully (see below) and returns an intest_instructions object".
> It goes on in that style. This is reminiscent of every bad attempt I saw during Java's heyday to ensure that a given codebase was 100% commented. People just end up writing "documentation" that consists of low-level repetition of what the code is doing
The problem, it seems, with people who try to do literate programming, is that they're too close to the thing to be effective at fulfilling the promise that literate programming sets for itself. I'm curious to see if the 3 years' overhaul changed Inform 7 substantially so that it's no longer on this track. Keep in mind that at the time, the slide containing that snippet was supposed to be a good example of literate programming—instead of what it actually was, i.e. an example of how not to do it...
Having had an opportunity to look deeper, I'm still disappointed.
As a reader, literature is pretty easy, comparatively speaking; it's got a straightforward user interface: you start at page 1 (or whatever) and just start reading. In some cases, maybe you give the whole thing a second readthrough and appreciate something that you missed the first time. But in any case, linearity is the key. Inform7, though it's not alone, appears to have fallen short. In the first place, I'm having real difficulty understanding where the author expects me to actually start. But moving on...
As far as I'm convinced, there is exactly one correct way to document code (whether you're doing LP or not), and that is to explain fully the problems you encounter and their nuances and, as a consequence, paint a picture of why, exactly, you have made the decisions that you have. It is _not_ to explain merely what your solution is and its parts—having already written it, but never having articulated concretely for the reader the problem driving you in the first place (if at all). This, too, is where most attempts to comment code fall short. I'm not getting any different feeling from Inform7. I can't help but feel as I begin trying to read through it that I've jumped into middle somewhere and have not actually started on page 1 since there's no way this narrative makes sense with that in mind.
The file you linked to reads to me like any ordinary block comment where the author struggles to convey their deep understanding to someone else.
Main.w in Chapter 1, after some attempt to be cute about the history of some procedures with similarly cute names like the "deputy", but nowhere explaining the problems that it will attempt to solve, starts right off[1] on line 30 by initializing four variables for which we have no inkling of their raison d'etre, but which presumably are supposed to make sense eventually, in true "Don't mind these" fashion[2]. It pretty much continues on in that vein—e.g. "@Start up the modules@" followed by a non-sequitur of a list of never-before-seen stuff (that, again, I'm sure will make sense eventually—once you've jumped in worked out the constraints and the "why" for yourself, just as you do with any traditional programming approach—but "literate" is not how I'd characterize it).
The whole thing, I'd say, suffers from a real bottom-up* mindset—where we spend a lot of time on things we have not yet seen a use for (and we're not user we'll ever see a use for at this point, but which we give the benefit of the doubt for, anyway), when really what's called for is an explication that is ruthlessly top-down[3] in its approach.
* unfortunately influenced, probably, by its roots in the culture of C—where you are forced to define things in a backwards sort of way, lest you have to add declarations for e.g. `bar()` before you're able to show in `foo()` how it is actually used—and where you tend to end up with `main` at the bottom of the file
I have quite a bit of respect for the fact that this is a successful, real-world program developed using Literate Programming. It's a style of programming which has interested me before, but like many other people, I've found it hard to do in practice, and tools to be lacking.
As an aside, the interactive fiction community is from a technological perspective a fascinating microcosm, including from a CS perspective. You have not just one toolchain, but an entire ecosystem of competing virtual machine specifications (Z-Machine, Glulx, TADS, Hugo), compilers, and source languages, all intending to deliver architecture-independence and the ability to preserve IF for the ages, yet apart from all general-purpose technologies typically used for the task.
Glulx is a simple, 32-bit virtual machine created to replace the Z-Machine. Both have numerous implementations. Glulx is itself used with an extensible I/O abstraction layer, and as I recall has been used with numerous I/O systems. Usually it is used with Glk, but I recall some outfits trying to sell commercial IF defined their own custom I/O system using the same Glulx virtual machine to provide greater capabilities.
Inform 7, as people are probably aware, is itself an experiment in source languages which read like natural language. The compiler produces Inform 6 as an intermediate language, and then invokes the Inform 6 compiler. The Inform 6 language as far as I'm aware was a product of reverse engineering the Z-Machine, and is completely different to the language Infocom originally used to produce Z-Machine images (though I believe that source is now released for those with historical interest).
It wasn't all Inform, though. TADS was an interesting second fiddle and one I personally preferred, being designed to appeal as far as I can tell more to programmers. The downside is it probably led to less popularity; though I personally don't really find myself thrilled at the prospect of writing Inform 7 with its unusual language, it's clearly won.
TADS 3 in particular featured an extremely sophisticated object-oriented virtual machine, which was very complex compared to the simplicity of the 32-bit Glulx machine. It's an impressive piece of technical work which I find fascinating, but my understanding is that despite fairly good documentation on the system's internals, nobody besides its original author ever managed to write their own implementation due to its intricacy. The VM is open source so this isn't the biggest deal, but having multiple implementations is a big deal, especially for something intended to allow works to be preserved through the ages.
Whereas the Inform ecosystem went with Glulx and the Glk I/O system, TADS chose to adopt HTML to facilitate formatting and multimedia functionality. This seemed like a natural choice, yet I distinctly recall finding it hard to find HTML TADS implementations for non-Windows platforms years ago. In the modern era, where people want to play IF in a browser, you would expect TADS to come into its own, but this has not been so. In a remarkably strange and in my view mistaken move, TADS chose to add web functionality by allowing (if I recall correctly) TADS projects to be recompiled so that the VM hosts a web server. Since it requires projects to be recompiled, and for two images to be shipped - one non-web, one web - it seems like an incredibly bad decision and undermines the whole point of having a universal image.
There are countless other engines, of course - ADRIFT, which was popular due to its GUI-based editor. "Hugo", which was used for the commercial game "Future Boy" and which emphasized multimedia capabilities.
Another angle to consider is sandboxing - all of these VM systems were designed to offer good sandboxing. Arguably the wider world is only just catching up with this now with the rising popularity of WebAssembly for non-web applications. The growth of the non-web WebAssembly ecosystem and sheer availability of different runtimes is really nice to see and the ready availability of VM systems which are both sandboxed and architecture-independent seems to be enabling all sort of interesting research and development. Who knows, maybe we'll see WebAssembly be adopted for IF-related use in the future.
I'd like to add that, perhaps surprisingly given how niche a field it is, the interactive fiction community keeps producing new languages and tools. In recent years, two new parser game programming languages have appeared: Dialog by Linus Åkesson (https://www.linusakesson.net/dialog/docs/index.html), a full-featured language inspired by Prolog; and Gruescript by Robin Johnson (https://github.com/robindouglasjohnson/gruescript), simpler but focused on creating web games, playable without writing, with a verb+object model like parser games.
One of the annoying things about TADS games from the user perspective was the limited selection of interpreters, because it wasn't open source. The Z-machine interpreters could be pretty nice and were widely available.
> TADS projects to be recompiled so that the VM hosts a web server
I don't know how long ago that was, but it wasn't always obvious that moving everything to JavaScript was the way to go for stuff like this. At one point that might have been a reasonable technical choice.
Well, Inform6-7 and the Z-Machine from mainframes like the TOPS20 OS from Ka10 made in the 70's to pocket devices with Android/iOS wins by a huge margin on freedom and sharing the game to near anywhere.
And with Puny Inform you could adapt a relatively small game to even the Commodore 64.
>(though I believe that source is now released for those with historical interest).
No. There was (and still it's) a huge ecosystem made with Inform6, even targetting the web if you chose GLULX and some of the settings which export the game for you.
There's Inform6, the Inform6 English Library (and some other s such as INFSP6 for Spanish, kinda close to the English one, the syntax is the same, even for the objects), and two manuals: the IBG, and DM4, the Designers' Manual, for hardcore people who want to create for example new libraries doing unusual things.
I'm unsure what you're responding to. The part you quoted refers to the original language used to produce Z-Machine files, ZIL. We know what ZIL looked like:
Ah, ok you meant ZIL and Muddle. Yes, I've know them, but I never used them.
Nowadays I've tried to ask some Dungeon/MIT maintainers to set Dungeon (Pre-Zork prototype which has the Zork I-II-III games condensed) under a free license, but I had no luck.
EDIT: Also, IF6 it's pretty good by itself, the included English library it's pretty good for a common game, reimplementing new objects it's trivial.
IF7 makes that easier, but forget about playing your games on DOS and Amiga machines.
For sandboxing and historical preservation, it helps that interactive fiction is text-based, single-player, and non-networked. I wonder if they've added any way to connect to a server?
There was a mud based implementation of Inform 7 based multi player IF platform called Guncho, but it’s not maintained. It was an interesting experiment.
assuming you're talking about z-machines, the only functioning way i've seen to get data out is to use savefiles. there is an editor written in inform that does this. otherwise the interpreter has to be modified, see multizork for example.
+1 for a nice review. You may be interested to know that there's been some success cross-compiling the command-line version of the TADS 3 VM interpreter to Javascript, I think you can play T3 games in Parchment now.
How hard do you need to pull on the thread of this question when the author of Inform (and the linked article) has already said GUI users will need to wait?
This is so exciting to see! I became obsessed with Inform7 a while back after I learned about it from "The best things and stuff of 2014" [1]. I remember scouring the web for its source code and being really bummed it wasn't open source. I can't wait to finally dive in! I've never seen a literate program of this scale before.
Can anyone offer a working link for a Javascript player wired up to a notable example? Weirdly inaccessible world. I found Slouching Towards Bedlam, but the site wants to run a Java applet
A major achievement IMO. I'm trying to think of what to compare it to so someone who knows nothing of Inform and interactive fiction can get a handle on it.
Maybe, it's like if they open-sourced Photoshop (and Photoshop -- as we know it today -- was the tool of a super-niche community)?
Inform 7 open source could be big news outside of interactive fiction. I met a EU air traffic control regulator who badly wanted "Inform 7 for business rules"
Yeah, I tought that. You can create a pretty small (ye hugely playable) game even for MSDOS and a 286 with Inform6 targeting the V5 version of the machine, and the V8 may requiere a 386 and up (any 24/32 bit machine in the end, think Amiga/Atari with m68k), but IF7 it's overkill, you can do a lot more than games.
Most games made with Inform6 are many times more complex than Infocom games (not to mention Zork/Dungeon and Adventure), so this is a crazy tool.
Inform 7 has a very primitive rules engine and (to me) a very interesting model in which defaults and the overriding of defaults is a major strategy of control. For instance the default response to you typing in a command is basically
printf("huh?\n")
and then the commands you can type in are defined in terms of exceptions to that rule, exceptions to those exceptions and so forth.
I tried to write a text adventure in Drools in a way inspired by Inform 7 and got to the 30% mark of a demo, I was convinced it was possible but that it wasn't for me because I couldn't make head or tail of the error messages I was getting because Drools syntax is an unholy mixture of the host language (Java) plus Drools-specific constructions. (One reason we can't have good things in programming languages is that we're still using your father's parser generators.)
(The other time I wrote something unconventional with production rules, which was the control plane for a stream processing engine, I had no trouble coding it and little trouble with the error messages because I could read and understand the source code for the Jena Rules Engines... That didn't stop the Jena maintainers from telling me that my use case was unsupported.)
It's sad that production rules became unfashionable when Duran Duran did because between the RETE algorithm, improvements on the RETE algorithm, and keeping rules in a hash table, production rules engines have improved dramatically since "expert system shells".
> (One reason we can't have good things in programming languages is that we're still using your father's parser generators.)
I don't think it's the parsing technology that's the problem. It's that designing a good grammar is actually quite difficult. It's like doing UX design, API design, and mathematics all at the same time.
I'd respectfully disagree. Sometimes the grammar is already defined, already exists, and you just want to parse it. Sometimes you want to make a new grammar based on one that already exists, for instance:
- add an "unless(X) {}" statement equivalent to "if(!X) {}" to Java
- add a new SQL literal type to Java that compiles to something like JooQ; to make it easy lets use Unicode characters like « » to switch languages
- almost any programming language contains an expression language that could be lifted out and used independently of the real language and slotted into another grammar (think making something like Python's list comprehensions, a business rules language, Microsoft's LINQ with SQL-like syntax)
All of the above should be a few lines of code on top of existing grammars.
Existing parser generators are one way: if they were two way (can unparse as well) you'd be in good shape for code generation.
You should be able to write your grammar together with your AST objects easily (don't get me started about Yacc's callback hell interface.)
The one feature I want from yacc is a PEG parser where it's as easy to set operator precedence as it was in the early C language parser. (Ought to be possible by rewriting the grammar... In fact there are a handful of problems with PEG parsers that everybody agrees should be fixable but nobody gets around to it.)
... and yeah, compiler books still say "Writing parsers that give comprehensible error messages is hard" without giving you any guidance as to how to do it.
An interesting summary is here: "Inform 7 for Programmers" by Ron Newcomb http://www.plover.net/~pscion/inform7.html