Roadmap Language Features - Glow-Lang/glow GitHub Wiki

Support for native asset in interaction
Interactions with two participants
Multiple asset classes in the same interaction. #7
Flexible number of asset classes (>3) #154
Private interaction parameters #47
Static number of participants greater than two in an interaction.
Dynamic set of participants in an interaction
An open set of participants in each of many roles in a DApp
"Choice" points / explicit timeouts / points where more than one participant may act. #25
Off-chain communication as part of the language
input function taking reflective context parameter, integrated with UI

Direct-style code generation
Automatic collateral insertion #26
Generalized State Channels #112
Space Compression A#128
Time Compression A#129
Some VM in Glow A#59 A#60 A#131 (see also Truebit, Fluence)
Logical queries about a monotonic verifiable data structure (based on CQL?)
zero-knowledge proofs for verification of arbitrary Glow interactions, so Glow can compile everything down to zk-SNARK's, and everyone watching the chain can see that some contract was invoked, yet no one can know what the contract was about unless a participant tells them what only they know—all that can be inferred is the number of steps taken.
Sufficient models of existing blockchains for interoperability A#110
Side-chain Markets with MKB A#54 ⇐ Beta network that enables a Token event
Operator Markets
Plasma Chains
Game-semantic enforcement of contractual obligations as logical predicates

One party must act, i.e. chooses whether to act or timeout.
"Small" functions (terminate within the transaction) with no reentrancy allowed.
Small functions, recursive, with user-specified loop invariants(?)
"Big" functions.
Multiple-worlds at the same time.
Race condition between multiple participants, typically in a contract where who wins the race ultimately doesn't matter: side-chain operators post independent transactions; higher bidders override lower bidders; a CRDT merges the results; etc.
Verification that these choices span all possibilities; drop checks that are not necessary considering the interest of the actor, e.g. if an actor may pick an amount for what they receive, it's their fault if they pick less than the maximum allowed, so the amount needs not be explicitly tested.