Patrick R. Michaud wrote (on p6c):
On Thu, Jan 15, 2009 at 08:53:33AM +0100, Moritz Lenz wrote:
Another thing to keep in mind is that once we start to have a Perl 6
prelude, we might decide to be nice neighbors and share it with other
implementations, as far as that's practical.
My guess is that there will be a shared prelude that is maintained
in a central repository like the spectests, but that individual
implementations are likely to want or need customized versions of
the prelude for performance or implementation reasons. In this
sense the shared prelude acts as a "reference standard" that
implementations can use directly or optimize as appropriate.
Now about the Perl 6 Prelude, rather than have customized versions, ...
A couple things I've learned from designing a language for implementation over
multiple architectures are:
1. It is usually possible to define almost all of the built-in types and
operators of a language in terms of each other using the mechanisms the language
provides for user-defined types and operators; left to itself this means the
language is recursively defined.
2. Each implementation architecture has its own concepts of what are the most
fundamental and efficient types and operators to use as a foundation. For
example, Haskell and Parrot would have many differences on what the fundamentals
are.
What I recommend, and forgive me if things already work this way, is to expand
the Prelude so that it defines every Perl 6 core type and operator using pure
Perl 6, complete enough such that there are as few as possible actual primitives
not defined in terms of other things. This Prelude would then be shared
unchanged between all the Perl 6 implementations.
Then, each implementation would also define its own PreludeOverride file (name
can be different) in which it lists a subset of the type and operator
definitions in the Prelude that the particular implementation has its own
implementation-specific version of, and the latter then takes precedence over
the former in terms of being compiled and executed by the implementation.
And so, as Perl 6 evolves or new implementations come along, the amount of work
necessary specific to the implementation to just get Perl 6 running at all is
minimal, and so more implementation specific work then is mainly for just making
it run more efficiently.
Take for example, non-integer numeric types and operators. These could be fully
defined in the Prelude or other plain Perl 6 file in terms of the (big) Int type
and its operators, so implementations only need native (big) Int support to get
all the other numeric types working for free. Then, if some implementations
want to get faster float or complex or small-int etc performance, they can
override with versions that use C-defined or machine native etc types and
operators in those cases. (As a more extreme example, you could also define
character strings etc in terms of dense arrays of Perl Int, and all the
complexity for Unicode etc would have a default implementation in Perl 6; in
that case, Str, and Perl identifiers, wouldn't be opaque but rather would be
class defs with array-of-Int attributes.)
So abstractly speaking the Prelude is still customized, but all differences from
the self-hosted shared one are in separate files.
So have I made any sense here, and what do you think?
-- Darren Duncan
