On Wed, 30 Aug 2000, Bradley M. Kuhn wrote:
> Dan Sugalski wrote:
> > At 04:25 AM 8/30/00 -0400, Bradley M. Kuhn wrote:
> > > > 2) Having a mechanism to automagically load in chunks of executable code
> > > > only when needed would be nice
> > >
> > >I would take this one a bit further:
> > >
> > > 2a) It should be possible, at compile-time, to detect what chunks will be
> > > needed and perhaps warn the user that they have gone beyond a subset of
> > > Perl they sought to stay within.
> > >
> > >This is primarily for compiling Perl to be run on embedded devices.
>
> > I was thinking of generalizing this so that the parser would pass on to
> > the bytecompiler (and then to the execution engine, whatever that may be)
> > that an add-on piece was used.
>
> That sounds like it fits with my idea. The question then becomes what is
> considered an "add-on" piece. I'd like to get very fine-grained with; even
> being able to turn of things as fundamental as tied hashes at compile time.
Well, the bytecode compiler will get all the bytecodes, so it can
presumably do whatever analysis it wants and if it sees bytecode for a
fundamental language feature that isn't supported (string eval, say, or
do/require) then it can yell.
On the other hand, it really wouldn't hurt to figure this out and pass on
the info to the compiler unit--if it doesn't get used, that's OK,
something else might later.
> I doubt anyone would have a need to do this except for the embedded device
> developers, but it would be best to be able to tell the embedded device
> developer at compile time that per code won't run because the embedded
> device is so small that it doesn't have the tied-hash support. ;)
Yup, I agree. Though I can see tied hashes making FurbiePerl easier... :-)
Dan
