Bad information on "what's new for Inform 6.3" page?

The official-looking “what’s new” page for Inform 6.30 (at Inform - Support - Inform63) mentions a new fake action:

GoneFrom 	is offered to the departure room's after property (after a successful movement, but before any arrival message is printed).

I can’t seem to find this in StdLib 6.12, though there is a new ##Going fake action that does something similar (allowing interruption by the arrival room’s .before() routine?).

It also mentions a new form for the objectloop statement:

objectloop (x : expresssion) 	is applied to every object x for which the expression is true.

However, this syntax does not seem to compile, even with Inform 6.36.

Are these unimplemented or abandoned ideas, or am I missing something?

2 Likes

That’s why I put “This site is no longer supported; information may be out of date” in the footer.

1 Like

Yes, but were either of these things ever true?

I tried compiling some code with the new form of objectloop on 6.30, 6.31, 6.32, 6.33, 6.34, 6.35 and 6.36, but each of them sees it as a fatal error.

Likewise, Standard Libraries 6.12.1, 6.12.2, 6.12.3 and 6.12.4 all seem to have ##Going instead of ##GoneFrom. (Neither is present in 6/11 or 6/10.)

2 Likes

Sorry, this question slipped.

I don’t know the status of these extensions. If you don’t see them in the source history, they don’t exist.

After 6.30, there was some work done by the people on the Inform mailing list for a possible “Inform 6.40”, which included some bigger changes, and these may have been part of that. That iteration of the project eventually ran out of steam, before being recast as it is now, essentially as “Keep Inform 6 working as it is and as Inform 7’s code generator, fix bugs but don’t change the language.”

1 Like

We have made some modest extensions to the language since 6.33.

If you want to propose something like the objectloop (x:expr) syntax, you can. But it would have to have a solid justification, not just “someone tried to do it 15 years ago”. And not break existing code, and not have too serious an impact on the codebase.

Thank you for the invitation, zarf.

I don’t think that it’s a necessary functionality. As far as I can tell from the brief description, the proposed function would be for

objectloop (x : x in bucket && x has light) ...

to work exactly as

objectlooop (x && x in bucket && x has light) ...

does now.

The only possible justification for it that I can conceive is that ITM 5.3 cites the current structure of objectloop's ospec syntax as the one of the greatest weaknesses of the I6 grammar from a technical standpoint. (See “a few critical comments on the above” item “a” near the end of the section.) It doesn’t look like the practical requirements of the compiler would be changed that much by implementing the proposal (reducing the maximum lookahead to 3 instead of 5?), so I’m not sure what theoretical gain there might be beyond a slight improvement in source code readability.

I was only asking because I wanted to be able to take advantage of that slight improvement to readability in my own code, and I was curious about whether it was a feature that was implemented at one time but later excised (in which case I would wonder why) or accidentally disabled (in which case I would hope for a fix). It appears that the proposal was never implemented in the first place, so that’s that. Thank you (and DavidK) for looking into the matter.

Yes, that’s how I read it too.

We’d have to keep supporting the existing syntax, so adding this wouldn’t reduce the lookahead requirement.