Thanks – that gets past the error I’d been seeing and brings us to…
→ An internal error has occurred: INVALID node type in Inter tree. The
current sentence is ‘if the player’s command includes “lie”’ (the Standard
Rules, line 2010); the error was detected at line 117 of
“inter/final-module/Chapter 2/Vanilla.w”. This should never happen, and I
am now halting in abject failure.
And so now I’ll report a bug…
On a related note—is there documentation anywhere for what subset of Inform 6 is now supported by the Inter translator? I’m simultaneously impressed by what it supports (Z-machine and Glulx assembly) and then by what it doesn’t (individual properties, apparently). And I can’t find this in the official documentation.
I’ve been noting things as I find them at I7-2102. And I7-2141 is on a related topic of a particular I6 inclusion/I7 invocation label not working together.
v10 has a more restrictive idea of what I6 reserved words are. A couple of extensions had to be modified because they used style as an I6 variable name, which I6 itself is fine with. But I’m not finding documentation anywhere obvious on what I6’s reserved words really are so I don’t know what other differences there are. Does anyone know where there’s a proper I6 reserved words list?
Other than those, I’m not sure anyone knows the answer: I don’t think Graham was adding restrictions on purpose.
Your Property statements alone compile if the rest of the extension is commented out. So something about this extension manages to confuse the parser, but I don’t think we can conclude that v10 doesn’t support individual properties.
The lexer tables in the I6 compiler are definitive.
Inform6/lexer.c at 193e0d9c3d788846c223a24762645a806d2d4dcb · DavidKinder/Inform6 · GitHub
Except not really, because most of those keyword groups are contextual. The opcode groups only apply when parsing an assembly language line. The directive_keywords and trace_keywords groups only apply inside relevant directives. misc_keywords is a mess.
I’d forgotten to mention one: I7 also doesn’t recognize the I6 built-in glk; its use will produce “unable to find definitions for the following name(s): glk”. (I’ve added it to I7-2102 now.)
I had looked at that but I would have naïvely thought it indicated that style was a reserved word, so I realized I didn’t know how to read it.
Having looked into reserved words in I6 further, I feel like I know less. This monstrosity compiles:
Global rfalse;
Global rtrue;
Global style;
Global font;
Global inversion;
Global spaces;
Global read;
Global restore;
Global return;
Global remove;
Global give;
[ Main default do else for if jump move objectloop switch until while
break continue print_ret quit new_line
win;
default = 1;
@setiosys 2 0; ! select Glk I/O system
win = glk($0023, 0, 0, 0, 3, 0); ! glk_window_open
glk($002F, win); ! glk_set_window
print default, "!^";
];
I have a guilty feeling that I come across as the moustache-twirling villain in this part of the thread, but perhaps I could just note that it’s not the intention for the I6-syntax-to-Inter part of the “building” module of “inter” to replicate the Inform 6 language in every detail. I6 is not quite as bad as Perl (about which it is famously said that “only Perl can parse Perl”), but still, it contains some real oddities. To replicate those would end up complicating the I7 compiler for no convincing gain.
In the end, dropping down into I6 to implement things is intended to be a last resort. A better goal is to make I7 more expressive so that people do not need it; I didn’t restrict the use of Include (- … -) to make an ideological point (it had to be restricted in order for the Inter transition to be possible) but, honestly, if a side-effect of these restrictions in 10.1 is that we end up with code more cleanly separating I7 and I6, that’s to my mind a good thing.
Anyway, these oddball I6 issues we’re seeing now mostly arise from old extensions which already needed a small amount of cleanup to work with 10.1, so that cleaning up their use of I6 syntax at the same time doesn’t seem unreasonable. Well - that’s what I think for now, anyway.
As Zed noted, the glk() built-in function is not supported, but there is now a better problem message to cover it than just reporting that no such function exists at linking time.
It’s true that at present we don’t support undeclared properties in I6 inclusions. Daniel’s right that this is potentially a compromise on the Z-machine, if it forces extensions to use up the limited supply of properties available. It might be possible to provide some slightly modified syntax to the Property declaration to declare a property, so that it does work in the world of Inter, but force it to be “individual” in I6 terms. I’m in two minds: depends how much people genuinely need this. In the end, the Z-machine hasn’t been the default target for Inform for quite a long time now, and any project needing multiple complicated extensions is probably going to be Glulx anyway. But do people disagree?
A Property propname individual; directive has been added to the I6 compiler in version 6.36 which does just that (predeclare a property without making it common), so perhaps it’s possible to adopt that syntax.
In the future I’ll be proposing to replace the flex system with Glulx malloc calls (perhaps with a limited compatibility layer for Zmachine, without multiple blocks though). If we could just target Glulx many things would be much simpler.
It would be interesting to think about what it would take to remove almost all uses of I6. Being able to define structs would probably be part of it. Lists that are closer to simple I6 arrays maybe?
I’d be much in favour of moving towards using Glulx malloc calls in place of the current flex code (on Glulx), yes. When this code was originated, it wasn’t quite safe to rely on Glulx memory allocation always being solidly implemented. But now I think it is, and the performance gains could be large.
Other way around:
Property individual propname;
But yes, I hope that helps.
My feeling as a software veteran is that that’s a better goal but we’ll never get there. Not unless we discard I6 entirely from the pipeline and use the C backend (or JS or whatever). And in that case we’ll need a way to drop down into C (JS, etc).
Two I6 parsers means ongoing pressure to converge them. Whether that means updating Inter’s I6 handling or deprecating parts of “classic” I6 will be a case-by-case decision.
I hope “classic” I6 will be maintained well into the future.
Ah! But now that Inform’s “Open Source”, who knows what could happen one wonderful day?
Also, to facilitate Inform reading your mind, maybe you should consider making your mind “Open Source” too?
So Inform can get at the internal workings?
I wouldn’t want Inform or pretty much anyone else reading my mind… 
Unless you can guarantee that your mental state conforms to some regular expression, I think you’re fairly safe…
I do think it would be useful, though, to have some documentation of what aspects of I6 syntax are supported by the Inter translator and what aren’t. If the glk builtin isn’t supported, my first instinct is to use the @glk opcode instead, but I don’t know if that’ll fare any better, and I haven’t been able to find anything about it in the docs.
The closest I’ve found so far is a mention in building:
Some antique syntaxes, such as for loops broken with semicolons not colons, are missing; so are some hardly-used directives; and the superclass :: operator; and built-in compiler symbols relevant only to particular virtual machines, such as #g$self, are not there. But really, you will never notice they are gone.
But the absence of individual properties is definitely noticeable (to me at least). I suspect this is documented somewhere, since the goal of literate programming is to have everything intrinsically be documented, but I’m not used to navigating webs and haven’t been able to find it if so.
(As a side note, I just discovered that the inversion statement is apparently supported by Inter. Out of all the I6 features I expected to have higher priority than individual properties, that was certainly not one of them!)
On this particular topic, I’d thought part of the purpose of dividing up the “kits” was to make the Z-machine a more plausible target again. Now it’s possible to jettison parts of the language and world model that aren’t being used, which seemed like primarily a concern on the Z-machine.
How large of an I7 game is able to fit on the Z-machine nowadays? I know that size decreased drastically back when “indexed text” was removed (so every game needed the text-processing system).
figured out what was the issue, i was building it with the package creator for the package manager of the OS i am using. it seems the problem was that the package creator adds some default flags to the build process cause the tools to not be created correctly so the tools were not able to build the kits even though they worked well enough to seem to work. i was able to add some variables to disable these default flags, which after building seems to build the tools correctly and the kits correctly now.
Also, just to check—is this an actual (report-filing-worthy) bug in inweb? Numbers in comments seem to disappear.
I’m assuming those comments are supposed to say “1st”, “2nd”, “3rd”, and so on.
EDIT: Never mind, I’m pretty sure this is a bug, because it apparently loses the first character of every comment. Now to go figure out how to report it.
It would seem entirely logical from a software development perspective to treat I6/z-Machine as a branch and separate release of Inform 10+ and have the main branch be pure Glulx. Dropping down to C would seem to be a healthy way to handle special cases. they really are different “domains” of IF implementation and keeping them “married” might muddle things. But I’m just thinking out loud. I’d be of no help on any of the work you people are doing.
