-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IE-0018: Use options and kit configuration #18
Conversation
Turns out everything I was thinking of asking about when I created the discussion PR is actually already addressed in the proposal, so I'll just say: this looks like a really nice improvement to use option organization. |
This is all so new that the paint is still wet on it, but I'm liking it so far. I don't know if you have a convenient way of searching your archive of I7 extensions seen in the wild? It would be interesting to extract the Use option... translates as... sentences found in them, and see what people are actually doing. I'm asking because I'm not sure how rapidly we should deprecate the old Use option... syntax, i.e., how soon we could look towards removing (- ... -) as a possible way to express it. If it turns out that almost all of the sentences anybody ever uses always take these forms: Use X translates as (- Constant IDENTIFIER = VALUE; -). Use X translates as (- Constant IDENTIFIER; -) ...then I could sneakily handle those without recourse to I6 insertions, just by parsing them directly, and that would make it less painful to withdraw the more general use of (- ... -) here. |
I had already looked, actually... there's one in the built-ins
and many in the 10.1 branch of the friends Repo (nearly the same as the 10.1 public library):
|
Thanks: that's very helpful, and makes up my mind to be slightly more aggressive about deprecating the old feature. What I've implemented today is that simple definitions of the kind in the list above will all continue to work as always, but in fact by being directly parsed to work out their intentions: i.e. if Inform can see that somebody just wanted to define a constant, then it goes ahead and does that, without injecting I6 code. More complicated definitions are rejected. This removes the code path from the compiler which creates Inter splat nodes from these definitions, which is a welcome simplification internally. Anyway, see the new section of the proposal on deprecation, which I hope is a reasonable policy line to take. I've replaced the line in Locksmith with
which turned out to be the only change needed: Locksmith, tellingly I think, wasn't actually using the constant However, doing this did bring to my attention that |
does this leave any recourse for access to kits' constants at assertion time without writing a kit oneself? I don't think it's outré to want to get one's hands on MAX_POSITIVE_NUMBER (which I see is now compiled directly into interb without occurring in the .i6t files. hunh). |
with the latter two being either-or. |
No description provided.