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
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
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 internal
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, if we can
"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 to
