Re: Working Group Proposal

> Horos <[email protected]> writes:
> >implementation with limits on the size of the arrays. IMO, you should be able
> >to configure at compile time:
> >
> >Include keyword 'open' in perl library? [y]
> ...
> >
> >So, what is really 'in the core' is just the syntax and the C code for 
> >parsing/interpreting that syntax. The 'outer core' (what we call the 
> >distribution now) would be intelligent defaults for these answers. The 
> >'outer outer' core would be a pdk of some sort.
> 
> I would go slightly further in one direction, and not as far in another.
> That is I would always build 'perl' as the minimal thing. BUT I would
> include in that minimum the ability to dynamically load the other bits.
> 
> Umpteen different perl executables with different capabilities 
> is not easy to manage. One tiny perl which adapts to how it is used 
> by calling for help should be.
> Nick Ing-Simmons


Ok, I'll go with that, but say you want to turn off certain features, ie: not 
be able to do system calls, or say use only part of the regex engine, or a 
different regex engine, or restrict functionality on *purpose*.

Or say you want to provide a smaller perl core without the necessary 'help'...
I suppose you could provide stubs to say 'this function is not available', or
point the perl executable to a different place to find (non-standard) 
functionality and have compile time directives to turn off these functions.

I like it... 

Ed