On Tue, Mar 10, 2009 at 12:46:29PM -0500, Jonathan Scott Duff wrote:
>     For those who are interested in adding some of the Perl 6
>     builtins to Rakudo's core settings files -- I've created
>     a wiki page that lists some prime candidates that I think
>     ought to be relatively easy to convert (perhaps using inline PIR).
> 
> Inline PIR would make the setting specific to an implemention that targets
> Parrot, would it not?  I thought part of the idea behind the setting was that
> it be usable by other Perl 6 implementations.  Is that just wishful  thinking
> on my part? 

The word "setting" here corresponds to the way it's used in the synopses --
it's the scope containing the builtin functions and methods defined
by the language (possibly a domain-specific language -- for Perl 6
it's called the "core setting").  The word setting does not mean 
"builtin functions that are written in Perl 6".

When writing the core setting files for Rakudo we're biasing 
towards pure Perl 6 where we can -- with the intent that these 
can be shared with other implementations.  However, I continue 
to believe there will be quite a few components and operations 
that will always be implementation specific.  That's where
the inline PIR comes in for Rakudo -- we still want to use
Perl 6 syntax to declare the methods and functions (because
we need multimethods signatures, binding, type checking,
exports, etc.), but those portions of the body that we can't
yet write in Perl 6 we can at least fill in with PIR.

Perhaps we need separate places in the repository for the 
"ready to be shared" and "not ready to be shared" components
of the setting; at this early stage of development I'm thinking
it's more important to organize the code by its function 
than by whether it's pure Perl 6 or has some inline PIR.

But, if there are other implementations that would start
using Rakudo's settings files today except for the existence
of the inlined PIR parts, I'm willing to reorganize sooner
rather than later.

Regardless, I think it's important that we use the
term "setting" for its synopsis meaning -- i.e., "scope
corresponding to linguistic setting", and not use it to
mean "a set of specific files shared by implementations".

Pm

Reply via email to