develooper Front page | perl.bootstrap | Postings from July 2000

Re: virtosity (was Re: Threads, reentrancy, and suchlike things)

Michael Stevens
July 24, 2000 08:57
Re: virtosity (was Re: Threads, reentrancy, and suchlike things)
Message ID:
On Mon, Jul 24, 2000 at 11:51:11AM -0400, Joshua N Pritikin wrote:
> On Mon, Jul 24, 2000 at 04:39:12PM +0100, wrote:
> > My thought - we should have a glib independant layer, so we can
> > use glib/nspr/whatever whizz-bang library is available.
> > But I fear this may be virtualising things too far.
> No, not at all.  Why shouldn't perl be able to adapt to any situation?
> Not only can perl6 be a tool for all jobs, but it's implementation can
> conform to a wide range of target sizes.  The implementation can become
> more modular with corresponding better support for module configuration.


We need a common subset of functionality, and we need to make that
available from one or more backend libraries, or there's no point to
the whole thing. 

Ideally it needs to be at least as efficent as using the code directly.
Tricky, without cpp evilness, or something very fun in our 
perl-implementation-> real code translator, and we can't make decisions
without knowing how that would be done.

Backend implementations need to be at least as good as we'd write the
code, ideally. I'm not commenting on anything existing, just stating that
as an obvious desirable feature, whether it's virtualised, or we use one,
or we write our own.

In fact, I could argue that modular design dictates that even if we
write our own, someone who wanted to should still be able to plug glib
in with very little work.

We need at least one implementation with a compatible license.

All features of _all_ backends should be available to the perl user. Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About