IE-0025: Kit-enumerated kinds

[curiousdannii]

• Proposal: IE-0025
• Authors: Graham Nelson
• Language feature name: --
• Status: Implemented but unreleased
• Related proposals: --
• Implementation: Implemented but unreleased

Summary

Extends the Neptune mini-language, by which kits can add new kinds of value to the
Inform language, to allow enumerations to be created whose run-time values are
not necessarily 1, 2, 3, ..., and no longer need to be contiguous.

[curiousdannii]

This looks great!

One question I have is whether it would be possible to define constants which already exist. For example, Inform defines all the various Glk constants, but Flexible Windows defines kinds for window type, position, scale method, etc. In 6M62 we have to map between the kinds, but it would be nice to just directly set the constants through kit-enumerated kinds. Could it be possible to define the constants twice and for it only to raise an error if it tries to set a different value?

The alternative would be for FW to just define winmethod_Proportional_ instead of winmethod_Proportional. As long as the values are the same it wouldn't matter to the code.

[curiousdannii]

Can values be hexadecimal, or only decimal?

[ganelson]

Fair question... They can now be hex, or binary, using the Inform 6 notations $ and $$. I've updated the proposal, and implemented this in the core Inform repository.

[ganelson]

One question I have is whether it would be possible to define constants which already exist.

To clarify: do you mean, if two different kits define enumerated kinds, and they both want to define the same constant? Or do you mean, if a kit defines an enumerated kind, can one of its identifier names coincide with a constant defined in some other way, e.g. by an explicit Constant declaration in BasicInformKit source?

[curiousdannii]

The latter. For example winmethod_Proportional which is defined by Architecture32Kit. A future version of Flexible Windows will likely include a kit which would define a window method enum.

It would be most ideal if we could define the same constant in FW's kit, and for it to be a no-op as long as it's the same value, but it would be fine if the kit just has to define a different constant name.

---

Just thought of another restriction the proposal doc could mention: I assume it's not possible to add extra values to these enums in another extension or in the story source, ie, that their options are fixed to what the neptune file defines?

[curiousdannii]

It doesn't seem possible to use kit enumerated kind constants to define another constant/array.

For example, I'm trying to define an array using the value of the last glulx feature:

Array Cached_Glulx_Gestalts --> (GLULX_GESTALT_Double + 1);

But when I try to use it, the index is out of bounds:

line 15923: ("helloworld.i7", 17): Error:  Array reference is out-of-bounds
>     DA_TruthState((Cached_Glulx_Gestalts-->(GLULX_GESTALT_Undo)));

I'm guessing that perhaps when the array is being constructed the value of GLULX_GESTALT_Double hasn't been backpatched, so it thinks it's 0?

[erkyrath]

Is this Inter or classical I6?

The compiler should yell about attempts to define an array length with a forward-defined or backpatched constant.

[curiousdannii]

Inter I guess? The source line is in a kit .i6t source file, and the error is from the Inform 7 compiler.

[ganelson]

Hmm. This should probably be filed as a bug report at Jira, then? In the mean time, a workaround is presumably to declare Cached_Glulx_Gestalts with an extent not derived from this constant?

[curiousdannii]

Yep, I'm currently just manually defining its extent.
I'll file it as a Jira bug.

[zedlopez]

It would be really nice to have the inverse of sequence number of, e.g.,

To decide what K is (name of kind of enumerated value K) number (n - a number): (- {n} -)

[ganelson]

How should that handle the case where the number doesn't correspond to a value of K? This would need to be typesafe, so it has to produce a valid K, and the difficulty is that we don't have optionals in Inform (much as that would be nice at times like this). Should it produce the K value closest to n? The default K value? Or throw a run-time problem?

[zedlopez]

I think runtime problem would be most appropriate.