On Mon, Nov 17, 2008 at 11:06:26PM -0600, Chris Dolan wrote: > Patrick has mentioned several times that the proper solution to the > problem is a representation of the high-level language that PGE can > interact with. My thoughts about that HLL mapping: > > 1) we should invoke the other language's compiler at compile-time and > generate an anonymous PIR .sub
This is the purpose of the --target=pir option to HLLCompiler. :-) > a) a special version of the compiler that just parses a block, rather > than a whole program (for Perl6 for example, I think the distinction is > irrelevant) This will likely become an option to HLLCompiler. > b) the returned PIR might have several subs. In this case, the > anonymous one will typically be short and will invoke the others > --> so there should be two return values: the library and the > entry point It's all PIR, so we don't really have to worry about that. The one to be invoked will be the one on top. > 2) the other language should be represented as an object which can: > a) parse a block > b) pre-process that block to insert boilerplate (see PIR_closure in > PGE::Perl6Regex today) for the anonymous entry point Again, this is the role of HLLCompiler. HLLCompiler doesn't have any of these features yet, but ultimately it will. > I thought about co-opting the PGE :lang adverb, which is currently a > string representing the compreg name. If that were optionally a > PGE::HLLMapping instance, then we could conditionally invoke some of the > behavior described above. It will continue to be the :lang adverb, and the HLLCompiler object named by lang will contain the mapping information (via a standard set of methods). Again, there are lots of pieces to this that are left to be implemented, but the basic design is somewhat in place. > > Remaining questions: > 1) what's the namespace of the generated code? Since PGE currently generates PIR, the PIR of embedded block(s) will likely be included as part of that (and therefore in the same namespace as the PGE PIR code itself). > 2) how do we handle languages where embedded code blocks are not > equivalent to whole programs? Do we subclass the grammar and redefine > TOP to be a statement block? In general, the HLLCompiler instance will override/provide a method that means "parse a block"; that method can call the appropriate rule directly. Or if the HLL compiler wants to subclass a grammar and provide a TOP rule it can do that -- it's really up to the compiler to decide the best way to do it. Pm
