@GrahamNelson recently wrote (in the “Inform 7 v10.1.0 is now open-source” megathread):
“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.”
This got me curious what he is considering “oddities”. I’m not an Inform6 programmer (at all!) but these are two I myself find a bit odd…
The use of --> instead of, for example, [] to access members in arrays.
The use of colons instead of semicolons in for-loops.
(There are most probably, even most likely, things here I can’t see through.)
Any other suggestions?
Disclaimer: This is just for fun, not in any way to criticise the achievement that I6 is.
Those are unusual choices compared to most C-like languages. (Also: [] to delineate functions.) However, they’re regular and easy enough to parse.
The oddities are stuff like the context-dependent handling of keywords, mentioned in another thread. Or the fact that the “preprocessor” is handled at the same level as syntax parsing. Or the fact that arrays are not comma-delimited, which means that Array foo --> 1 2 -3; is ambiguous.
Also that I6 has a few features in which old syntaxes were deprecated but never withdrawn - such as having semicolons dividing “if” statements. I6 still reads “for (i=1; i<=10; i++)”, even though the proper syntax is now “for (i=1: i<=10: i++)”. The I6-syntax-to-Inter compiler inside I7 does not recognise the deprecated version, only the “modern” one. (Modern here means “after about 1998”, I think.)
I very often forget the ; and in the end, this odd construct of Inform 6 led me to use the then-novelty syntax colouring (colouring whose led to zero the errors caused by the [ instead of [; )
The lack of delimiters in general. Zarf mentioned the issue in arrays, but it’s also a problem in e.g. the action-invocation syntax.
Apart from that, the number of things that are keywords instead of built-in functions. For example, there’s a keyword box to print a quotation at the top of the screen, and a keyword inversion to print the game version information. Most of these, I believe, do actually just call built-in functions (in the veneer layer), but they get special syntax for historical reasons.
Dictionary words use the same syntax as individual characters ('single quotes'), meaning there needs to be a special syntax for making a single-character dictionary word. However, there’s an exception to this when defining the name property of an object, for historical reasons; double-quotes can be used there. (I’ve never actually seen this exception used myself, but it’s described in the Inform Technical Manual and I trust that.)
It’s not always clear what’s case-sensitive and what isn’t. Identifiers, for example, aren’t, including anything authors define in their own source. But built-in function names are! Directives like Array aren’t, but control flow instructions like if are.
On a related note, directives sometimes have to be preceded with a # sign to mark them as such, but other times don’t (specifically they need to be marked if they’re used inline, inside a routine).
All in all, I6 is a language with a lot of historical baggage for the purposes of backwards-compatibility, and I certainly don’t blame Graham for not wanting to replicate the entire parsing process in the new I7 compiler. (I’m just looking for some good documentation on what is and isn’t supported.)
Most of the oddities I encounter are in the library, rather then the language. Here’s a couple in the language that have tripped me up in the last week:
The declaration of a Constant doesn’t require an equals sign (=), but a Global does.
The caret (^) is used for a single quote in dictionary words, a carriage return in printed strings and the actual character in string constants.
When printing oddball characters, sometimes you use (say) @@94 and sometimes you use @{94}.
