I suggest you ...

Allow constants I7 constants to be linked to I6 constants

Currently you can define constants only for kinds of value in Inform 7. You can define variables and objects with the "translates into I6" syntax, but you can't use that to define them with a I6 constants. Well variables can, but they're not treated as constants in I7, and you can't use them in tables for example. You can't define an object constant by the translates syntax because you'll get an I6 error about using the name twice. It would be useful to be able to bring an I6 constant into I7, especially if it's not limited to kinds of value only.

0 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    curiousdannii shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    3 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • Andrew Plotkin commented  ·   ·  Flag as inappropriate

        Yeah, I can't see how I7 can cope with a column type of "window or this arbitrary constant". Someone could say "printed name of wintype_AllTypes" and then the VM crashes.

        (Unless I7 adopts a full-on ML-style algebraic type system. Which falls in the category is "would be awesome and very difficult".)

        For kinds of value, I agree it would be safe. Not sure what the I7 syntax should look like, but storing GG_MAINWIN_ROCK in an I7 table is a valid use case.

        (The variable solution looks like "Mainwin-rock is a number that varies. The mainwin-rock variable translates into I6 as "GG_MAINWIN_ROCK"." Not only is this not a useful constant, it turns into an I6 compilation error as soon as someone writes "mainwin-rock is 1".)

        A completely different solution to your problem would be a phrase "sort (table) in (column) by (phrase) order". That is, a user-specified ordering function, so you wouldn't have to rely on I6 address order. But that's a different feature request.

      • curiousdannii commented  ·   ·  Flag as inappropriate

        My current use case is that's I'd like to be able to store a table column of g-windows, with some of them being wildcards like wintype_AllTypes. This is so that I can sort the table and have those wildcards come up first.

        I can create a g-window variable and translate it to that I6 constant but I can't use a variable in a table. I can't create a g-window object and translate it to that I6 constant because then the constant is being used as an object name.

        What I've had to do is create some g-window things and define them first for the sorting to work. The extra memory doesn't really matter and I don't need to them to be defined by the constants. But it isn't as cool.

        Maybe doing this with objects is dumb. I'm sure it would be quite safe with kinds of value though. The same problem applies with numbers. We can define a number variable and translate it to a constant, but it can't be used in tables. It would be useful I'm sure to be able to store "GG_MAINWIN_ROCK" in a table. Currently you'd have to define either an I7 constant and risk it get out of sync, or define an I7 variable and put it in the table at run time.

      • Andrew Plotkin commented  ·   ·  Flag as inappropriate

        If you brought an I6 object reference into I7, what kind would it have? I'm not sure if the I7 object system can cope with objects that it didn't create.

        (That is, I'm sure it can't deal with them now. I'm not sure how it could be extended to. If you define your own I6 object and declare it to be an I7 thing, it would be missing all the properties that make I7 things type-safe and iterable.)

      Feedback and Knowledge Base