On 11/9/06, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
Opinions welcome. Personally I think I favor the "a compiler is an object with a 'compile' method" model, and that C<compreg> gives us back a compiler object as opposed to a subroutine-like thing.
Would it not be possible to support both? A compiler compiles, so it seems natural to write quick-and-dirty compilers as simple subroutines. Also for wrappers around other compiler codes, they still could be useful if they compile/execute, while there is not a full-blown implementations in terms of the Parrot compiler API . The usage patterns could be something like: .local string perl6_source .local pmc perl6_compiler perl6_compiler = compreg 'Perl6' $P0 = perl6_compiler(perl6_source) (Yes, the same as Patrick's first snippet.) And then perl6_compiler = compreg 'Perl6', OBJ # OBJ is some constant $P0 = perl6_compiler.'compile'(perl6_source) "compreg S" would be short for "compreg S, SUB" or something (and it could be always required). While "compreg S, OBJ" may blow with a "non implemented feature for some compilers". It would be easy for object compilers to provide a sub implementation. But on the other hand it could also be easy for subroutine compilers to provide an object implementation with the help of a wrapper object (with not very useful methods besides 'compile'). My $0.02 cents. Adriano Ferreira.
