What is the reason that the Inform 6 library requires the programmer to include three files - why not two or four - and what parts of the library have to be in part 1, part 2 and part 3 respectively, for everything to work?
Modularity. If you were to rewrite part of the parser, you could replace Parser.h (or parserm.h) and leave the rest of the include files alone. Or similarly one of the others.
It could have been two or four or six include files, but this is the way Graham chose to split it up in early versions of Inform and it never got changed.
(Replacing one of the header files entirely did not turn out to be a popular way of customizing Inform. There were some library replacements that replaced all the files, and others that replaced just a couple of functions from one file. But Graham didn’t know this would turn out to be the case when he started designing Inform!)
1 Like
It doesn’t have anything to do with replacing routines?
I’m currently having some problems in PunyInform, where replacing the routine PrintShortName seems to cause total chaos with some calls to PrintShortName using the library’s version and some using the game’s version of the routine.
PunyInform currently has two files that the game programmer has to include. This allows the user to define routines between these two include statements which the library needs to know that the game programmer has defined and still let these routines refer to global variables which are provided by the library.
I also noted that Platypus uses three include files, but without giving them names that say what they do, they’re just called First, Middle and Last.
Not that I know of.
That shouldn’t happen but I’d have to see some sample code.
1 Like
I know there was a recently-fixed bug in I6: this would happen when a replaced routine was referenced before the Replace directive. But that should be fixed now; are you using the latest compiler?
1 Like
What bug was this? Are you thinking of http://inform7.com/mantis/view.php?id=1094 ?
EDIT: This must be what you are thinking of, yeah. The exact problem was noted as:
The problem case seems to be only when the function is called between the original definition and the replacement definition.
I don’t remember how this works for veneer routines like PrintShortName.
The fix was in 2016, but that was after the formal 6.33 release so if you’re on 6.33 you might not have it.
2 Likes
I’m using 6.33. Will switch to 6.34.
1 Like
Yep, that’s the one! I misremembered what exactly made it happen, just that under certain circumstances the original version of a Replaced routine would get called inconsistently, and that it was fixed in 6.34.
1 Like
As historian, I’m piqued by the fact that both Inform Library and Infocom’s ZIL library uses three files and in more or less the same partition between the three files:
gparser.zil --> parser.h
gsyntax.zil --> grammar.h
gverbs.zil --> verblib.h
Best regards from Italy,
dott. Piergiorgio.
1 Like
It’s rather hard to tell since Infocom didn’t treat their parser as a library in the strict sense. The Zork 1/2/3 code has those files, but also has gmain.zil, gmacros.zil, gglobals.zil, and gclock.zil. Most of their other games have files named parser.zil, actions.zil, syntax.zil, and verbs.zil, but the boundary between parser code and game code is fuzzy.
I can confirm that the problem went away when I switched to Inform 6.34.
3 Likes
Good. I’ve submitted an I6 pull request to update the ReleaseNotes.html file, explaining the improved behavior of Replace in 6.34.
2 Likes
Albeit there’s no filestamps, the general dating can be done thru the known version/release date, and albeit I haven’t done a systematic research, seems there was an evolutionary process from adhoc, even haphasard, coding toward an increased parser standardisation. (you have fixed a sort of “minimum standard” with your playing IF card…)