Front page | perl.bootstrap |
Postings from July 2000
On Mon, Jul 24, 2000 at 11:51:11AM -0400, Joshua N Pritikin wrote: > On Mon, Jul 24, 2000 at 04:39:12PM +0100, mstevens@globnix.org 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. Thoughts: 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.