Joe McMahon writes:
: On Thu, 24 Aug 2000, Stephen P. Potter wrote:
: 
: > I have several RFCs I need to write about removing certain functionality
: > out of the core (math functions, IPC, networking, "user").  I don't want to
: > go too overboard.  I don't know that we want to go so far as to remove
: > printing and such.  It might be nice to generalize some functions (like the
: > discussion with open() that happened awhile back).
: 
: Hard things should be easy, easy things should be trivial. We should try
: to keep the stuff that is commonly used in the core (excluding OS
: dependent stuff, perhaps? Non-Unix folks don't see the use for getpwent(),
: for instance). In my opinion, Perl6 should still be a language in which
: it is easy to write powerful and useful programs on the command line.

We're fighting multiple definitions of "core" here.  Please distinguish
the core of the language from the core of the implementation--they're
two entirely different things.  What we're attempting to do here is
make it *not matter* whether something is in the core implementation or
not.  This gives us a great deal of freedom in how to implement the
core of the language.

For instance, if I'm running Perl on my Palm, I'd just as soon that
index() were implemented in Perl using repeated substr() comparisons.
Yes, that's slower than the C implementation, but the representation is
much more compact, and might have a hope of getting shoehorned into a
small memory.  A Perl distribution might implement index() much as it
does now in portable (more-or-less) C.  A distribution intended for a
high-powered server of known architecture might substitute in a
hand-coded assembler version of index().  A JVM implementation might
call out to some core JVM routine.  An .NET implementation might
delegate indexing to some object running on index.microsoft.com.  :-)

This should all be transparent at the language level.  Certainly
index() will continue to be supported in the core language.  But it
almost certainly belongs outside the core implementation.

Larry

Reply via email to