Inform 7 v10.1.0 is now open-source
intfiction.org
intfiction.org
An interesting summary is here: "Inform 7 for Programmers" by Ron Newcomb http://www.plover.net/~pscion/inform7.html
It's under the Artistic License 2.0: https://github.com/ganelson/inform
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.
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.
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—
Previously:
> Have a look at this slide in particular: <http://inform7.com/assets/images/NS2/slide036.jpg> Here's an excerpt:
> "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
<https://news.ycombinator.com/item?id=25594817>
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...
https://github.com/ganelson/inform/blob/master/inform7/imper...
This comment style seems pretty reasonable and informative.
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
1. <https://github.com/ganelson/inform/blob/e723c36deef41bea793a...>
2. <http://akkartik.name/post/literate-programming>
3. <https://www.teamten.com/lawrence/programming/write-code-top-...>
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.
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.
The Guide:
https://www.inform-fiction.org/manual/download_ibg.html
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.
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.
Coincidentally, I've been playing with web assembly the past few weeks. That yielded https://dungeo.org, though it's still very much a WIP.
This has no sense. Compare it to Collosal Cave Adventure, which can be run near anywhere.
> 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.
And with Puny Inform you could adapt a relatively small game to even the Commodore 64.
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.
The GUI isn't available until 3rd party developers release it in May --- currently it's command line only.
https://github.com/TobyLobster/Inform for MacOS, maintained by Toby Nelson
https://github.com/DavidKinder/Windows-Inform7 for Windows, maintained by David Kinder
https://github.com/ptomato/inform7-ide for Linux, maintained by Philip Chimento
[1] http://blog.fogus.me/2014/12/29/the-best-things-and-stuff-of...
From: https://ifdb.org/viewgame?id=032krqe6bjn5au78
The JS player link is:
https://iplayif.com/?story=https%3A%2F%2Fifarchive.org%2Fif-...
Note that it loads instantly in Chrome, and is hanging in FF, don't know why sorry.
You don’t need to be a fan of Interactive Fiction to appreciate how brilliant this work is.
Inform 7 is really intriguing.
Maybe, it's like if they open-sourced Photoshop (and Photoshop -- as we know it today -- was the tool of a super-niche community)?
Ah, maybe it comes bundled.
Great news. I prefer Inform6, but having free languages to code IF it's always good.
But I think there's room for another attempt after 60 years.
https://en.wikipedia.org/wiki/OPS5 https://en.wikipedia.org/wiki/IBM_Operational_Decision_Manag...
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")
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".
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.
- 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.
And the i7 compiler it's almost a simple English parser by itself.
https://github.com/briangu/OPS5/blob/master/demo/ops-demo-ma...
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.
It's like a literarian Prolog.