Skip to content
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-0010: Concepts #10

Merged
merged 1 commit into from
Aug 1, 2022
Merged

IE-0010: Concepts #10

merged 1 commit into from
Aug 1, 2022

Conversation

curiousdannii
Copy link
Collaborator

  • Proposal: IE-0010
  • Authors: Emily Short and Graham Nelson
  • Language feature name: concepts
  • Status: Draft
  • Related proposals: IE-0009
  • Implementation: None

Summary

A new top-level kind of object, concept, useful for representing abstract concepts like "forgiveness" or "Italian cookery" which have no physical existence in the world model.

@curiousdannii curiousdannii added the formal-proposal A formal proposal that has been accepted for consideration by the core Inform team label Aug 1, 2022
@ganelson ganelson merged commit f1d70f4 into main Aug 1, 2022
@curiousdannii curiousdannii deleted the ie-0010-concepts branch August 1, 2022 13:37
@2lindell
Copy link

2lindell commented Oct 6, 2022

Hi,
I wanted to know if this proposal could be expanded to include not just concepts, but also glk objects and events. Sound files are already integrated, but not windows or any events. The existing extensions that incorporate these are not done well (for example - making windows as the kind "containers"!)

@2lindell 2lindell mentioned this pull request Oct 6, 2022
9 tasks
@curiousdannii
Copy link
Collaborator Author

Just copying these comments from #12 across:

Oh, I hadn't thought of the idea of a more general abstract kind, but yes that would make sense. Maybe just "abstract object" with support for a generic kind of containment, which could then be customised for each kind by using new verbs? ("The verb to spawn means the containment relation.")

The new "concept" kind (#10) might even make sense to be a sub-kind of abstract object? Similarly in a mystery game, authors could make a subkind for clues, a philosophy game could have theorems, and so on. While most of these uses of abstract objects probably would need many-to-many relations, there might be some (other than glk windows) which just need a one-to-many and could piggy-back on the containment relation by use of a verb alias.

@zedlopez
Copy link
Collaborator

zedlopez commented Feb 21, 2023

Make the token [D], where D is a description of a kind of object which is not a kind of thing, automatically infer any. In particular, [concept] would always mean [any concept], i.e., there would never be any attempt to apply touchability or visibility to concepts.

Neither change affects the meaning of existing source code.

This does affect any existing source code that uses non-thing objects (without any) as tokens. Small Kindnesses by Aaron Reed, for instance, uses '[room]' as a token and relies on placing specific rooms in scope for those commands to apply to those rooms.

The current state of affairs, where "visible" means "every, in or out of scope, in or out of play" and "touchable" means in scope plus one of: a room, a region, or an actually touchable thing, is highly confusing and a routine problem point for new users. Adding another exception to track, that any means the same thing for things that the absence of any means for non-things doesn't make things clearer.

I think a better choice would be to leave any in grammar tokens as is and to add new qualifiers to action specification assertions, for instance unconditional as a synonym for visible (and just saying that makes much clearer what visible really means) and scoped meaning what it sounds like. (It could be just defined in the docs as customary that when you're using concepts you generally want one unconditional concept.)

And I take it thing in action definitions continues to mean object and not thing ?

Edited to add: never mind the reference to scoped; that should remain the parser's concern and not be part of action specifications.

@zedlopez
Copy link
Collaborator

zedlopez commented Jul 6, 2023

If a story has a dialogue section, both the dialogue and concepts language elements are automatically activated. Would it be possible to automatically activate concepts if a story (that doesn't have a dialogue section) creates a concept? Or was this deliberately avoided so as not to conflict with any stories that might have created their own "concept" kind?

It seems like the only way to activate it otherwise is with project_metadata.json, which is somewhat cumbersome (though I'd assume it'll be just a click-a-checkbox affair for IDE users, and if it would be a fuss to implement auto-activation, I think CLI users can cope with maintaining a project_metadata.json file).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
formal-proposal A formal proposal that has been accepted for consideration by the core Inform team
Projects
None yet
4 participants