Where do we go from here? - A strawman walk through design space. What is the objective? For THIS NOTE, it is "create a system that can closely track the Snn spec". It is NOT clear this is the right objective. Does this require self-hosting? No. Does this require a flexible parser? Yes. But, an interesting alternate objective is "system with working oo, with pugs(current)-level parser flexibility". Or perhaps even lower flexibility. I'd simplify this note by choosing that as the objective, but there is a choice point below which flexibility bares on, so we'll carry it along. What are the system components and what is working? runtime core - yes (pugs, pil2js, p5) objects - not quite (pugs, pil2js, p5) compiler - yes? (pugs) parser - not quite* (pugs) [yes? if inflexible is ok] Are capabilities worth breaking down? I'm not sure. The key ones seem to follow the components. * Compiler: Existing systems: Only pugs. input: pugs parser (currently no alternates) output: pil, pugs ast (pil is currently partial) status: not sure. I've a fuzzy impression of "causing problems" and "needs rewrite". yes? If that's the state, then the key question is how difficult would it be to fix/reimplement? In hs p6 some language (js, p5) Fix/reimplementation on hs I'll leave for others to outline. Reimplementation on non-hs: p6 requires working objects could run on pugs, pil2js, or p5 p5 either running a compiler written in p6, or written directly in p5 if the p5 is p6-ish enough to make it feasible complexity wise. js probably only option is run a "written in p6". (every time I say "js" in this note, I mean the "js liked with perl5" hybrid) What would a compiler in p6 look like? Takes a parse tree. Output options: Drop in replacement: PIL-like but with class info. Direct emit: AST->native, no PIL stage. p5: could do either. no currently working PIL->native stage. js: could do either. but the existing PIL->native state works, and removing might be non-trivial. Key question: How hard would it be to write a compiler in p6? Don't know. Issues: pugs compiler buggy? or not? Options: fix, reimplement. pugs compiler->PIL is lossy. no class info. Options: fix, might work around, reimplement. * Parser Existing systems: Only pugs. output: pugs ast, -CParse-YAML status: is key. I have no idea. Key questions: - Does yaml non-lossily reflect the parse? - How well is the parser working now? Causing any bugs? - Does it seem ok going forward? Sort-term? All the way to a dynamic parser sandwich? Flavors of parser support: - static p6 prelude - operators can be added (current pugs) - full Snn spec dynamism Implementation options: Use pugs parser. Via yaml if compiler is non-pugs. Build on pge. Write a parser in p6. (requires working objects. probably) There may be other options, depending on exactly what is needed. Building on PGE: Can it handle a p6-sized grammar? unclear. but it would likely be fixed if it didn't. Could do static with just a grammar. Would need wrapping (dynamic grammar creation), or callbacks (dynamic nodes - may or may not be tractable) to add operators or be spec. p5 could call pge. a js_p5 hybrid could call pge. Write a parser in p6: Mostly just a rule engine (ie, PGE in p6). Not that hard, I think, with exceptions and hypothetical variables. Gets cruftier without, but still doable. Performance may be an issue. One possibility is to write in p6, and then transcode to js or p5. * Notes We currently have a number of almost-but-not-quite systems and components. What are possible objectives? Find a series of actions which give us: any one system to have working objects? a min cost (or min risk?) path to a Snn tracking implementation? What other possible objectives? What cross-cutting constraints? performance? Performance wasn't discussed above. Perhaps it should have been. Key question - just how much do we not care about the performance of our possible implementations. Note that with multi-step bootstraps, the performance of the initial stage may not matter. Some scenarios: - fix pugs add: almost working, and is being tested. disadd: developer accessibility/availability limitations add: may be minimum cost path to "basically working objects". but high risk? - js core (in a js-p5 hybrid) add: already works and being tested. disadd: development is in js. iblech has been only major developer. - fix PIL to contain class info. teach js to understand it. add: may be minimum cost/risk path to "basically working objects". - get class info direct from source, bypassing compiler - via custom regexs disadd: very hackish and fragile. - via -CParser-YAML ques: plausible? - p5 core add: could build on exiting p6-ish modules. ques: how robust are they? how bad is the performance? add: development process could look like normal cpan growth. disadd: object zoo has to be built from scratch. perl5/Perl6-Value and Container is _not_ a usable foundation. - fix PIL to contain class info, and write PIL->native compiler. add: re compiler - has been done, can be done again. - write -CParser-YAML -> native compiler add: might be simplest p5 core approach. disadd: -CParser-YAML is an untried component. - parse and compile on p5. independent of pugs. - p5 parse disadd: slow, doesn't exist - pge parse add: faster, almost maybe exists disadd: wrapping and system complexity issues. - parrot bootstrap add: pge is there, and thus interoperation with it is cleaner. add: is a possible long-term right thing. disadd: developer accessibility/availability limitations disadd: very flakey platform disadd: not a high-leverage environment - good developers can take a long time to do something small. Some non-existent components: - a parser written in p6. perhaps a transcoding of same to p5. - a -CParser-YAML based compiler. written in p6 or p5 or js. to pil or native. Ok. That just hit my self-imposed 1hr timeout. First draft.