On Thu, Nov 09, 2006 at 09:55:05AM -0200, Adriano Rodrigues wrote: > 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?
Sure, it's possible to support both -- we can even handle both types within the existing Parrot framework. I think I'm basically asking which model will be considered the "Parrot standard"? > 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) We could do this now without requiring an additional parameter to C<compreg>, by adding suffixes to the compiler name. For example: $P0 = compreg 'Perl6_sub' # get subroutine view of compiler $P0 = compreg 'Perl6_obj' # get object But I find the suffix (or the use of an extra parameter) a bit overblown. I'd rather come up with a standard API for compilers that supports all of this, and then individual compiler subs can deviate from that standard if it's really appropriate. I've also just written a HLLCompiler base class (I would've called it 'Compiler', but that name is currently taken in Parrot) that makes it easy to wrap a sub into a compiler object. Thus registering a new compiler becomes: load_bytecode 'Parrot/HLLCompiler.pbc' .local pmc compile_object, compile_sub compile_object = new [ 'HLLCompiler' ] compile_sub = get_global 'name_of_compile_sub' compile_object.'compsub'(compile_sub) compreg 'MyCompiler', compile_object Using the compiler is then: .local pmc mycompiler mycompiler = compreg 'MyCompiler' $P0 = mycompiler.'compile'(source) Thanks for the excellent comments! Pm