On Thu, 2009-01-15 at 16:03 -0800, Darren Duncan wrote:
Patrick R. Michaud wrote (on p6c):
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.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.
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 maintainedAnother 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.
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.
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.
implement each feature in terms of some number of other features. The
creators of the shared prelude are then stuck with the problem of
deciding which of these to use. If their choices do not match the way a
particular implementation is designed, it will then be necessary for the
implementation to replace large swaths of the Prelude to get decent
performance.
For example, implementations in pure C, Common Lisp, and PIR will
probably have VASTLY different concepts of available and optimized
primitive operations. A prelude written with any one of them in mind
may well be pessimal for one of the others.
That's not to say it's not a useful idea for helping to jumpstart new
implementations -- I just somewhat doubt that a mature implementation
will be able to use more than a fraction of a "common" prelude.
-'f
P.S. I did this sort of thing once -- a Forth prelude that attempted to
minimize the primitive set, and it *was* very nice from an abstract
perspective. Unfortunately, it also made some operations take millions
of cycles that would take no more than one assembly instruction on just
about every CPU known to man. It's a REALLY easy trap to fall into.
