Front page | perl.bootstrap |
Postings from July 2000
At 02:47 PM 7/24/00 +0000, Simon Cozens wrote:
>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.
Are you speaking of glibc here? Assuming you are, there are a few problems:
1) Last time I checked, glibc's license isn't compatible with perl's, and
I'm really hesitant about using code we can't use as a reference. (It feels
like stealing, even if it might not be in direct violation of the licensing
agreement)
2) Another implementation is just that, an *implementation*. I'm not
looking for the final product--I'm looking for the theories. Final product
is nice in some ways, but its already made tradeoffs, and they may not be
the ones we need to make. They might be, and that's just fine, but I can't
make a good decision unless I know.
3) I, for one, work better from documentation and theory papers than from
code. It's a personal quirk
4) glibc seems pretty darned Unix-specific. That's OK for it, certainly, as
Unix is its target, but we're working with a different problem domain.
>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?
If the wheel doesn't fit for one reason or another, then we need to
reinvent it. (And many of these wheels we've already got) Also some of the
wheels people have invented are... suboptimal.
>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.
In some ways perl's living in a very different world than most programs,
and the use of other folk's canned solutions may not be optimal. Perl's a
language interpreter, and it lives at the same level as glibc and friends,
and just a half-step up from the kernel.
Chip quoted someone in his Topaz talk (and I don't remember who) "It's not
that I mind giving up a factor of two in performance, but neither do nine
of my friends". There's nothing wrong with using library code, but we
*must* make sure it's as efficient as possible, and it *is* worth us
rewriting the bits that don't cut it. If libc's IO, for example, was fast
enough we wouldn't already be bypassing the interface and messing about in
the guts.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
dan@sidhe.org have teddy bears and even
teddy bears get drunk