"David Grove" <[EMAIL PROTECTED]> wrote :
> But.. but... but... we don't even have a design spec. I mean, we don't
> even know for sure what Perl 6 is going to look like for certain, inside
> or outside.
This is precisely why I proposed the BS level just below Development. In fact I'm
going
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:19 AM 11/17/00 -0800, Ken Fox wrote:
> >However, I don't want to see early (premature) adoption of fundamental
> >pieces like the VM or parser. It makes sense to me to explore many
> possible
> >designs and pick and choose between them. Also,
I agree with Dan's proposals for PDDs. In particular I like the idea of
the WG chairs having decision power -- it should protect us somewhat from
design-by-committee syndrome.
However, I don't want to see early (premature) adoption of fundamental
pieces like the VM or parser. It makes sense to me
At 10:19 AM 11/17/00 -0800, Ken Fox wrote:
>However, I don't want to see early (premature) adoption of fundamental
>pieces like the VM or parser. It makes sense to me to explore many possible
>designs and pick and choose between them. Also, if we can keep external API
>design separate from interna
At 09:27 AM 11/17/00 -0800, Ken Fox wrote:
>When we put scanning garbage collectors into perl, we should
>provide an alternative for foreign code.
We're likely going to have a scanning GC of some sort in perl 6. It'll
probably only touch memory perl manages, and there'll be some way to
register
I used the Elk 2.x series extensively in several engineering
applications I wrote for Ford Motor. It was a nice system in
general, but perl's XS (and guts documentation) was much better
than Elk's. One of the biggest problems with Elk is that it
has a scanning garbage collector, not a ref count co
