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

Evaporating Cloud syntax - Request For Comment #4

Open
raymyers opened this issue Jan 27, 2023 · 1 comment
Open

Evaporating Cloud syntax - Request For Comment #4

raymyers opened this issue Jan 27, 2023 · 1 comment
Labels
question Further information is requested

Comments

@raymyers
Copy link
Owner

raymyers commented Jan 27, 2023

Evaporating Cloud (AKA Conflict Resolution Diagram) syntax RFC

The purpose of this issue is to gather feedback and counterproposals for TOC-Lang's Evaporating Cloud syntax. We are currently in a prototyping phase where it is safe to break compatibility, so this is the best time to shape our notation for the future.

Please comment your thoughts, thanks!

Entities

Unlike in the other Thinking Processes, all Evaporating Cloud diagrams have the same node labels related in the same way.

  • A == the objective
  • B, C, D, D' == conditions believed to be required by the objective, always related in the conventional way
    • A requires B
    • A requires C
    • B requires D
    • C requires D'
    • D conflicts with D'
  • Injection == an action that can be taken that breaks one of the dependencies, resolving the conflict
    • The suggested convention is to use **Inject** or **Assumption** in the edge label, but it accepts arbitrary text
    • Both an injection and assumption can be supplied using a multi-line "-quoted string

Example Cloud

A: Maximize business performance

B: Subordinate all decisions to the financial goal

C: "Ensure people are in a state of optimal performance"

D: "Subordinate people's needs to the financial goal"

B <- D: **Inject** Psychological flow triggers

D': Attend to people's needs (& let people work)

Check src/assets/grammars/toc-lang.peggy for the grammar specification.

Open questions

To make injection and assumption labels easy, probably **bold** should be processed by default in edge labels. Does that mean all markdown should? d2lang has a special syntax to enable markdown, would it be better to follow that? Tentatively thinking parse only **bold** by default and later can add the full markdown mode. This only hurts the use case where we want literal double-asterisks to show up, probably no one needs that.

@raymyers raymyers added the question Further information is requested label Jan 27, 2023
@raymyers
Copy link
Owner Author

raymyers commented Dec 16, 2023

Historical note. The RC1 syntax shown below is now abandoned in favor of RC2 patterned after d2lang.

A is "Maximize business performance"

A requires B, "Subordinate all decisions to the financial goal"

A requires C, "Ensure people are in a state of optimal performance"

B requires D, "Subordinate people's needs to the financial goal"
inject "Psychological flow triggers"

C requires D', "Attend to people's needs (& let people work)"

D conflicts with D'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant