Allow top-level lsm layer to be constructed first

[sanderr]

Use case

Force lsm top-level instance creation to finish (breadth-first) before continuing execution. The main motivation is to not trigger side effects (e.g. allocation) until all instances are constructed. This allows us to guarantee that no side effects will happen if e.g. an instance fails to construct because of an index collision.

Other potential benefits could be to avoid list freezes unitl all instances are unwrapped etc.

Ideas

(brainstorm-grade)

Atomic for

A new type of statement for a non-gradual, atomic for loop:

• non-gradual: waits for entire iterable to be complete
• atomic: collects all child requires and waits for them, then schedules all child blocks simultaneously

  atomic for instance in lsm::all(...):
  MyEntity(...)
  end

Open questions/issues:

• what if allocation is part of the for body?
• the current proposal does not yet make it truly atomic: substatements are still scheduled as normal, just together. What if the body contains a conditional statement. Do we want to dig even deeper for requires? Make the atomic for a resumer that keeps rescheduling itself until all requires are effectively resolved, then execute_direct its blocks?

immediate keyword

Add an immediate (/ urgent / ...) keyword that signifies that a statement should get priority. This would allow for a two-layered execution: the compiler guarantees that no non-urgent statements (with some well-defined exceptions) will be executed until the urgent ones have finished execution.

immediate condition = true

for instance in lsm::all(...):  # parent of immediate statement -> immediate itself but other children aren't
    immediate MyEntity(...)
end

Alternatively, the keyword could be part of an entity definition.

Open questions/issues

• With partial compile, indexes are not a suitable guard for the primary invariant check. Instead, I believe plugins / allocation is used, which is exactly what we're trying to postpone here.
• Instances may be constructable, contracting them through indexes, without causing conflict. Then when execution continues conflicts may arise due to non-index assignments. So the above may only work if the service identity also comes in over the API (e.g. service_id is the instance id). In that case there will always be a conflict between this index and any other ones that would contract.

[edvgui]

what if allocation is part of the for body?

I can tell you it most certainly is, this is the only way to not have the allocated attributes set to null on the constructed object (as the api requires a default value defined in the model for these read-only attributes). The alternative to setting these attribute in the constructor call is to call the allocator plugin everywhere we need it, but this looks a lot less clean (imo).

With partial compile, indexes are not a suitable guard for the primary invariant check. Instead, I believe plugins / allocation is used, which is exactly what we're trying to postpone here.

This makes me think that the way forward is maybe simply to make it easier for the developer to check these index constraints with plugins. I think it would be possible to have such plugins with a generic implementation, looking up the relevant index in the model, and making all the required checks based on the service attributes (not the service instance). Such plugin could then be called as the condition of an if in which the instance would be constructed.