On Thu, 2009-01-15 at 16:03 -0800, Darren Duncan wrote: > 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. > > 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.
The problem with this method is that there are usually *several* ways to 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.
