Adapt to `23w31a`+

[intsuc]

• Implementation suspended until the macros specification is likely finalized
• Design suspended until a new function execution model is implemented

  This data pack version removes the recently introduced execute if function and return run functionality. Flaws with those commands (see bugs MC-264595, MC-264699 and MC-264710) require some substantial changes to fix, which we do not want to make close to a release.

  These commands will instead be reintroduced early in the next snapshot series when we can take the time to iterate on and test them together with pack makers.

• Box's supported versions start with 23w31a the appropriate version after 23w31a
  • Older versions are too restrictive:
    • No overlays
    • No macros
• Macros should be used explicitly if there is a performance overhead
  • Macros, especially parsing, are too slow!
• Representation in type is still necessary?
  • Using compound stack makes representations unnecessary, but takes more time and memory
  • As long as list tags are homogeneous, representations are still necessary?
  • Selective monomorphization?
• Remove two-level type theory for a while?
• Compile-time only things no longer exist
  • All we need is a better way to control optimization
  • Runtime only things still exist (e.g. commands)
    • Even runtime-only things no longer exist by adding the special world type
• Dynamic command generation
  • Arbitrary command generation is unsafe!
  • Appropriate abstraction is necessary
  • Type-safe macros using powerful type system?
• Macro definitions?
  • To explicitly inform overhead of macros
  • Can always be used as a function definition
• Heaps
  • Typed list heaps that can be accessed in Θ(1) time?

    $data get storage heap: string[$(index)]
    

  • Typed array heaps using ByteArrayTag/IntArrayTag/LongArrayTag?
  • Compound heaps are the best for memory allocation? https://github.com/intsuc/mem

    $data get storage heap: $(addr)
    

• References to values on the stack

  $data get storage stack: int[$(addr)]
  

  • This means that we don't need the heap for values with a lexical lifetime!
  • The heap is used for passing values to the future contexts
• Selective parameter specialization?
  • Similar to polymorphism using intensional type analysis
  • Explicitly select parameters to ensure optimization
  • How to statically ensure that a given parameter is in canonical form without 2LTT?
    • Phase system?
      • Orthogonal to type system?
      • Sub-phasing const <: world
      • Examples:

        /command :: world
        0 :: const
        
        world def seed() : i32
        seed() :: world
        
        def +(a : i32, b : i32) : i32
        +(0, 1) :: const
        +(seed(), 1) :: world
        +(0, seed()) :: world
        +(seed(), seed()) :: world
        let x := seed(); x :: world
        let x := {a: 0, b: seed()}; x.a :: const?
        let x := {a: 0, b: seed()}; x.b :: world?
        

    • Effect system? α <: α ! { world }
      • Examples:

        0 : i32 ! {}
        seed() : i32 ! { world }
        
        +(x₁ : i32 ! e₁, x₂ : i32 ! e₂) : i32 ! (e₁ & e₂)
        +(0, 1) : i32 ! {}
        +(seed(), 1) : i32 { world }
        +(0, seed()) : i32 { world }
        +(seed(), seed()) : i32 { world }
        

      • Problem:

        let x : i32 ! {} := seed() : i32 ! { world }
        # x is now const!
        

    • Homogeneous multi-stage programming?
      • Problems:
        • Can't use commands in compile-time world type
        • No canonicity world type
    • Closed/crisp modalities?
      • flat modality
      • sharp modality
      • Type-directed selective specialization?
    • Constant Evaluation - The Rust Reference?
• Constant-time function dispatch

  $function $(name)