Brainstorm of possible futures for niecza

futures.txt

"Compiler core" = src/*.pm6 except STD

Choose compiler core language.

Perl 6:
  When the setting is being recompiled, how is the current setting
  distinguished from the new one?

  The compiler does not depend on anything from the setting:
    How are compiler references to kernel objects resolved if not via CORE?
    TODO

  The setting is not compiled, it's all C# code:
    When the setting is replaced, do we have to rebuild everything right away?
    If not, how?  If so, how will the compiler be rebuilt?
    TODO

  The new CORE is sandboxed in a separate compartment within the same runtime:
    How does interaction occur across the sandbox wall?
    How do we handle version skew for CORE instances?
    Can objects be shared directly?  This has the potential to majorly screw
    up bounded serialization.
    TODO

  The new CORE is sandboxed by a separate instance of the runtime (status quo):
    Do we always sandbox in this way, or only for CORE and perhaps also the
    compiler?
    How does interaction occur across the sandbox wall?
    TODO

C# or other 'standard' CLR language:
  Sandboxing and metaprogramming are simplified greatly because the compiler
  can always hold direct references to user objects and vice versa.

  Since the compiler no longer requires a Niecza runtime, version skew issues
  are completely eliminated.

  However, parsing is a problem: STD is the only reasonable way to parse full
  Perl 6 (especially once 'is parsed' enters the picture).  I am thinking of
  writing a MiniParser.cs and using that to parse a hacked version of STD which
  does not require the setting.

  Also, I feel dirty for leaning towards this.

  TODO

Something custom:
  Not going there.  If I'm going to reinvent NQP.net, I might as well just quit
  and switch to working on Rakudo/6model/dotnet.

--- A different classification ---

Type A:
  The compiler is strongly isolated from the user runtime.  This is the
  current approach, but seems to have many disadvantages:

  * User code cannot use compiler-domain metaprogramming functions or
    vice versa.

  * Requires lots of glue to translate data back and forth.
    - Every manipulation procedure requires a wrapper

  * Requires keeping track of several incompatible interfaces

  * Very awkward build procedure.

  ...

Type B:
  These futures involve the compiler running less isolated from user
  code, allowing metaprogramming functions to be shared and reducing
  glue requirements.

  Some of them have a Perl 6 compiler component.  This requires the ability
  for the compiler to replace itself and/or the setting, and also requires
  a way to port the compiler to an updated kernel.  Presumably after this,
  there would be no more forward incompatible changes to serialization.

  Another very promising Type B approach uses a pure C# compiler component,
  which does not depend on the setting and thus does not have any bootstrap
  issues.

  I want to move to a Type B approach but Type B Perl6 approaches seem to
  have intractible bootstrapping problems.  See above.