The compiler does not detect that the constants for the Dictionary directive are not declared. However, it assigns them a value.

Dictionary 'word' DICT_XXX DICT_YYY;
[ main;
   print ('word'->#dict_par1), "^";
   print ('word'->#dict_par3), "^";
];

162
35

(instead of 128, 0)

Several directives permit using a constant, but the constant must already be defined. (It can't be defined after the directive.)

The compiler was not properly checking for this error. Now it does.

Release CONST;
Version CONST;
Dictionary 'word' CONST CONST;
Iftrue CONST;
Iffalse CONST;

Tests at https://github.com/erkyrath/Inform6-Testing/tree/undef-constant-errors .

Fixes https://github.com/DavidKinder/Inform6/issues/84 .

Several directives permit using a constant, but the constant must already be defined. (It can't be defined after the directive.)

The compiler was not properly checking for this error. Now it does.

Release CONST;
Version CONST;
Dictionary 'word' CONST CONST;
Iftrue CONST;
Iffalse CONST;

Tests at https://github.com/erkyrath/Inform6-Testing/tree/undef-constant-errors .

Hi @jolyot

Thank you for the kind words and not a bad idea, thanks for the suggestion as well.

We'll consider this for future releases.

This seems possible.

However, in general, we can't give warnings about forward-declared symbols. (Forward-declared symbols should work in all these cases, but we can't retroactively give warnings about improper usage when the symbol is later declared.)

Normal library usage declares properties and attributes up front, so that will be fine for most people.

First, thank you for the awesome product.

What I would like to suggest is to add iOS frameworks other than "iAd.framework, AdSupport.framework, and CoreTelephony.framework from here to ios.weak_framework in podspec.

In particular, AdServices.framework, which will replace iAd.framework in the future, should be added. Furthermore, as mentioned in this issue, Xcode12 and iOS14 have been officially released, so I think AppTrackingTransparency.framework can be added.

(Check other "definite value" errors, e.g. in the Release directive. They may have the same bug.)

That is, if the constants DICT_XXX or DICT_YYY are not yet defined, the compiler silently generates an incorrect dictionary. It should throw an error: "a definite value must be given".

Probably just need to change

                if (module_switch && (AO.marker != 0))

to

                if (AO.marker != 0)

in a couple of places.

The compiler does not detect that the constants for the Dictionary directive are not declared. However, it assigns them a value.

Dictionary 'word' DICT_XXX DICT_YYY;
[ main;
   print ('word'->#dict_par1), "^";
   print ('word'->#dict_par3), "^";
];

162
35

(instead of 128, 0)

Fixes https://github.com/DavidKinder/Inform6/issues/81 .

In v3 only, if two dict words differ only in Z-characters 7-9 (the chars that are not stored in v3), the compiler would generate two dict entries containing the same word. This fixes that.

Test: https://github.com/erkyrath/Inform6-Testing/blob/master/src/dict-cutoff-v3test.inf . This tests a bunch of cases for both v3 and v4+. No compiler bugs were found for v4+.

See also https://github.com/erkyrath/Inform6-Testing/blob/master/src/dict-cutoff-alttest.inf (v4+ only), which tests cases using a modified Z-character alphabet.

Compile this with Inform 6.34, using -v3

Array buffer -> 100;
Array parse -> 100;


Object Being "human-like being"
	with
		name 'human' 'human-like' 'being';

[ Main i;
	print "Contents of Being.name:^";
	for(i=0 : i < (Being.#name / 2) : i++)
		print i, ": ", Being.&name-->i, "^";
	buffer->0 = 80;
	parse->0 = 20;
	@sread buffer parse;
	print "Contents of parse buffer:^";
	for(i=0 : i < parse->1 : i++)
		print i, ": ", (parse+0)-->(2 * i + 1), "^";
	@sread buffer parse;

];

Then run this in Windows Frotz and type this input: "human human-like being".

Apparently, human and human-like make two different dictionary words when compiling, but they are the same word when Windows Frotz looks up the words the player typed in the dictionary. I tried this in Gargoyle (Bocfel) too, with the same result.

The way I read the Z-machine spec ( https://www.inform-fiction.org/zmachine/standards/z1point1/sect03.html#seven ):

• 'human' should be stored as first 'h' 'u' 'm' 'a' 'n' and then Z-character 5 as padding
• 'human-like' should be stored as first 'h' 'u' 'm' 'a' 'n' and then Z-character 5 for shift (which should then be followed by Z-character 28 for '-' but that's truncated since we've run out of space)

So they should be identical as dictionary words, no?

Inform 6 has some operators where the operator on the left hand side must be a valid object ID and/or the one on the right hand side must be an object ID, a property ID or an attribute ID. In a few cases, giving the wrong kind of entity raises a warning. I can see that these operators confuse a lot of newcomers to Inform 6, and even I made a stupid mistake in this area recently ( "if(player has necklace) ..." :) ). Wouldn't it be nice with warnings when using the wrong kind of entity for these operators? Like for Lamp.light = true or if(Lamp provides light) etc. Here's a program covering some of the cases, with comments for the ones that currently give a warning.

Property p1;
Property p2;
Property p3;
Property p4;
Property p5;
Property p6;

Attribute a1;
Attribute a2;
Attribute a3;
Attribute a4;
Attribute a5;
Attribute a6;

Object o1 "o1"
	with
		p1 1,
		p2 1,
		p3 1,
		p4 1,
		p5 1,
		p6 1,
	has a1 a2 a3 a4 a5 a6;

Object o2 "o2";

[main;
	if(o2 has o1) print "o2 has o1";
	if(o2 has p1) print "o2 has p1"; ! Warning: Property not qualified by object
	if(o2 provides o1) print "o2 provides o1";
	if(o2 provides a1) print "o2 provides a1";
	if(o2 in p1) print "o2 in p1"; ! Warning: Property not qualified by object
	if(o2 in a1) print "o2 in a1";

	if(p1 has a1) print "p1 has a1"; ! Warning: Property not qualified by object
	if(p1 provides p1) print "p1 provides p1"; ! Warning: Property not qualified by object
	if(p1 in o1) print "p1 in o1"; ! Warning: Property not qualified by object

	if(a1 has a1) print "a1 has a1";
	if(a1 provides p1) print "a1 provides p1";
	if(a1 in o1) print "a1 in o1";

	if(o1.o2) print "o1.o2 ~= 0";
	if(o1.a2) print "o1.a2 ~= 0";

	give o1 p1; ! Warning: This is not a declared Attribute: "p1", Bare property name found. "self.prop" intended?
	give o1 o2; ! Warning: This is not a declared Attribute: "o2"

	give a1 a2;
	give p1 a2; ! Warning: Bare property name found. "self.prop" intended?
];

You were able to get it working for V4?

V4 works but you need the Metro84 library. Or no library -- most of the tests in this repo don't include a library at all.

I've fixed the comment and added some test lines. Thanks.

The new tests for v4+ look good.

I think the comment "! A four-byte character in the seventh place leaves zchar 6 followed by no bits" should say eighth place, no?

Also, I miss a test to check that a shift to A1 in the ninth position is different from a shift to A2, which they should be. Like:

test_different('abcdefgh$', 'abcdefgh_');

You were able to get it working for V4? I've been having trouble with even producing a V4 due to problems in the veneer.

The new tests for v4+ look good.

I think the comment "! A four-byte character in the seventh place leaves zchar 6 followed by no bits" should say eighth place, no?

Also, I miss a test to check that a shift to A1 in the ninth position is different from a shift to A2, which they should be. Like:

test_different('abcdefgh$', 'abcdefgh_');

Over at https://gitlab.com/DavidGriffith/inform6unix I'm experimenting with the idea of being able to select which library the author wants to use with a minimum of hassle. I've worked out a scheme that seems to work by requiring the use of a Makefile or else requiring the author to type in a long override of Include_Path by way of the +dir flag. I'd like to be able to do inform -L std foo.inf to compile something using the Standard library and inform -L puny bar.inf to use PunyInform. This would easily extend for any number of alternate libraries.

I envision this happening by reworking the *_path parameters that are compiled into the compiler. For instance, have lib_path contain /usr/local/share/inform/lib. Then in /usr/local/share/inform/lib would go subdirectories for whatever libraries desired. The -L flag would select what subdirectory to choose. So -L std would include files from /usr/local/share/inform/lib/std. Includes would be the same way: /usr/local/share/inform/include/std and so on because the includes mostly seem very library-specific.

How does this sound, at least in concept?

For the time being, I think that having authors call punyinform mygame.inf to get things set up correctly will suffice.

Actually the problem is slightly more subtle than I phrased it above. But whatever, it's fixed.