Front page | perl.bootstrap |
Postings from July 2000
Dan Sugalski (lists.bootstrap): >At 07:56 PM 7/19/00 -0700, Russ Allbery wrote: >>Benjamin Stuhl <sho_pi@hotmail.com> writes: >> >> > 2 more (neither of which the current parser satisfies): >> > * reentrant, as much as possible >> >>Thinking about threading and re-entrancy from the very beginning of the >>design is *vital*, IMO. > >Anyone got pointers to papers or publications on these subjects handy? I encourage you - nay, I encourage *EVERYONE* - to look at glib. It's got threading. It's got safe signals. It's got hashes. It's got arrays. It's got a main event loop with scheduling. It's got safe memory allocation. It's got hook functions. It's got IO disciplines. It's got platform independent type support. It's got automatic cache support. It's got dynamic module loading. How many of these wheels are we prepared to reinvent? And, more importantly, why? I *really* hope one of the aims of Perl 6 is to benefit *everyone*, not just Perl users. I've been working on Unicode stuff in Perl recently, and then it dawns on me that if I look at libunicode, all the code I need is there. It's already done. I've been duplicating effort. That sucks. Perl has been so amazingly insular to date. CPAN teaches us that code reuse is good, and that if some piece of available code doesn't meet our needs, we refine it and send back the changes to the maintainer. If we base a Perl 6 on libunicode and glib and iconv and whatever, I believe we can fix their deficiencies and give the results back to their development communities so *everyone* can benefit. It helps them, because their libraries become more efficient and more complete. It helps us, because we can develop a lot faster. It helps Joe Random Hacker, because, thanks to us, he's got a better set of tools to work with. And it helps Perl PR, because "these Perl guys are so nice, they provided a bunch of optimizations to our code". Think it over. :) -- "The elder gods went to Suggoth and all I got was this lousy T-shirt."