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
