I7 access kind-related I6 object properties?

Authoring Inform 7
1

When objects are declared at the I6 level, there are properties established for them (IK*_Count and IK*_Link) with information about their context within the kind hierarchy. For example, a person might include:

Object -> I126_bob ""
	...
	with IK8_Count 1		! <--- second of N people (zero-indexed)
	with IK8_Link I127_carl	! <--- next person
	...
;

Is there any way to refer to these values programmatically in I7 code? The properties can be hardcoded at the I6 level, but ideally I would like a way to refer to them so that if the kind’s numeric ID changed it would not be necessary to update the code.

I hoping for something like:

To decide which number is the index of (V - value of kind K) within (name of kind K):
	(- {V}.IK{-mystery-invocation:K}_Count -).

where -mystery-invocation is some actual code. (Neither -strong-kind nor -weak-kind work correctly in this position; they always evaluate to 10.)

1 Like
2

I believe this is part of why Basic Inform and the Standard Rules have to define their kinds in a specific order: because the kits need to be able to refer to these properties and there’s not a better way than hardcoding the kind numbers.

1 Like
3

I think there are two choices here:

  • hack the I7 compiler
  • write a script to consume and replace the I7 compiler output (becoming the filling of an Inform 7-Inform 6 compiler sandwich)
4

On the plus side, because the compiler is now open-source, it should be a fairly straightforward pull request to add this new -mystery-invocation. No idea if it’ll be accepted, but it seems like a simple improvement.

5

Why do you need this value in I7 code? Just wondrin’

I believe these properties were added to speed up looping over instances of a kind in I6 loops

6

I wanted to use these as coordinates for a 2-field array with rows of kind K and columns of kind L, so I was looking for a generalized way to take advantage of what’s already there.

1 Like
7

So you’re really interested only in the kind’s index number (2 is Thing, 8 is Person…) rather than the IK2_Count, IK2_Link properties?

8

For what I was working on, what I really wanted was the value stored in the IK*_Count property for any given object. I was looking for a mystery invocation because that seemed like the most elegant way to get at the fields in question for every defined kind.

For the special case of the specific value of one of those fields for any one kind, it’s easy enough to declare a to decide... phrase such as:

To decide which number is index of (P - person):
	(- {P}.IK8_Count -).

That’s brittle for kinds that aren’t built-in, though, because changes in declaration order change the assigned number embedded in the property names.

I don’t have any particular use case beyond that specific desire.

9

I think it would be better to set up your own properties and not try to leverage the internal IK*_Count stuff.

10

Every object has a property KD_Count which holds the enumeration x of the kind it belongs to, as used in IKx_Count and IKx_Next.

The KD_Count of all people is, for example 8

2 Likes
11

In Ver 10 you also need the I7 name of the kind in order to reconstruct the property names, which take the form IK<kind_ID_No>_<kind_name>_Count and IK<kind_ID_No>_<kind_name>_Next

You can get that from I7_Kind_Name(<kind_ID_No>), which prints the I7 name of the kind.

None of this is necessarily stable across I7 versions, so if you are planning to create monumentum aere perennius, as usual Zarf’s advice may be wise

EDIT sorry. I7_Kind_Name() takes <kind> as parameter, not <kind_ID_No>

12

Furthermore, in Ver10 you run into the problem that the relevant property names are not yet defined at the point of I7 compilation, (it happens later at the stage of Inter processing) so attempts to reference them via I6 inclusions in I7 code will fail.