On Wed, Dec 06, 2000 at 02:05:32AM +, Simon Cozens wrote:
> decent implementations, and we don't have enough experience of it. C's
> portable and everyone knows it, but it's a swine for doing OO things.
but perl5 is *still* encountering platforms that don't fully meet the 1989
ANSI spec for p
On Tue, Dec 05, 2000 at 11:12:01PM -0500, Bradley M. Kuhn wrote:
> helps people think about the issues. However, I would like it to be
> possible for a programmer of language Foobar to take the specification of
> the data structures and implement them directly in Foobar without too much
> trouble
> No, there isn't. I object to targetting GCC specifically for two reasons,
> though, neither of them VMS related:
>
> 1) Targeting a single compiler, no matter whose it is, is a bad idea. We're
> writing in a *language*, not for a compiler. Targeting a specific compiler
> restricts us even mo
Simon Cozens writes:
> This is not a design document; it's a meta-design document - that is, it
> tells us what things we need to design, the things we need to consider
> during the design process of the Perl 6 internals.
Thank you!
> Why does string C have to screw everything up?
It doesn't.
On Wed, Dec 06, 2000 at 08:31:07AM -0700, Nathan Torkington wrote:
> Simon Cozens writes:
> > Why does string C have to screw everything up?
>
> It doesn't. String eval is the escape hatch from a language that
> can't do what you want it to do. As such it's okay for it to be
> slow--consider it
At 07:49 AM 12/6/00 -0800, Daniel Chetlin wrote:
>Simply deciding that `eval STRING' is "unimplemented" on these
>theoretical ports and binary compiles is the best idea I've heard yet,
>but we should remember that `require' is built on `eval STRING'.
That's not necessarily the case. If we allow f
At 08:31 AM 12/6/00 -0700, Nathan Torkington wrote:
>Simon Cozens writes:
> > Today's scary thought:
> >
> > use B; my $main_root = new B::OP;
> > ...
> > my $int = new B::Interpreter; $int->run($main_root)
>
>That's yesterday's scary thought. Today's scary thought is making
>a perl5
At 06:47 AM 12/6/00 -0800, Evan Howarth wrote:
>Perhaps a hybrid approach would solve all the language needs. Retain
>reference counting. When the count drops to zero, call the destructor and
>mark the object. Free marked objects when sweep runs. To reclaim circular
>references, the sweep task
On Wed, Dec 06, 2000 at 01:15:07PM -0500, Dan Sugalski wrote:
> What I'm thinking is that we'll have a scoped destruct stack that gets
> pointers to variables that explicitly need destruction, and as we exit
> levels of scope we call the destructors of those variables that need it.
> (They can
Simon Cozens wrote:
>
> =head2 Implementation Language
>
> C++ gives us OO and headaches, is wildly non-portable due to a lack of
> decent implementations, and we don't have enough experience of it. C's
> portable and everyone knows it, but it's a swine for doing OO things.
Don't forget we can
On Wed, Dec 06, 2000 at 11:48:45AM +, Nicholas Clark wrote:
> (Is maintaining such a document an "apprentice" job? (see perl6-meta))
I'd certainly like someone to take on the maintainance of the document I
posted last night, because I hope that one of its functions will be to explain
to appr
On Wed, Dec 06, 2000 at 08:31:07AM -0700, Nathan Torkington wrote:
> > Today's scary thought:
> >
> > use B; my $main_root = new B::OP;
> > ...
> > my $int = new B::Interpreter; $int->run($main_root)
>
> That's yesterday's scary thought. Today's scary thought is making
> a perl5 XS
Oh boy, it's OO syntax nargery time again. *sigh*.
On Wed, Dec 06, 2000 at 10:51:14AM -0800, Nathan Wiger wrote:
>@array->length
>%hash->keys
>
> Simply keeping @arrays and %hashes as buckets for SV's wouldn't let you
> do this.
I don't think that's true. At all.
> An "SV" would really
On Wed, Dec 06, 2000 at 10:51:14AM -0800, Nathan Wiger wrote:
> Don't forget we can mix-and-match C/C++ to some degree
for added portability!
--
If computer science was a science, computer "scientists" would study what
computer systems do and draw well-reasoned conclusions from it, instead of
At 02:39 PM 12/6/00 -0500, Bryan C. Warnock wrote:
>In http://www.mail-archive.com/perl6-internals@perl.org/msg01766.html,
>Dan outlined rev 2 of the RFC process, PDD (Perl Design Docs).
>
>Everything seems rather specific to internals - will there be a separate
>mechanism in place for all-things
At 07:55 PM 12/6/00 +, Simon Cozens wrote:
>Oh boy, it's OO syntax nargery time again. *sigh*.
>
>On Wed, Dec 06, 2000 at 10:51:14AM -0800, Nathan Wiger wrote:
> >@array->length
> >%hash->keys
> >
> > Simply keeping @arrays and %hashes as buckets for SV's wouldn't let you
> > do this.
At 07:34 PM 12/6/00 +, Simon Cozens wrote:
>On Wed, Dec 06, 2000 at 10:51:14AM -0800, Nathan Wiger wrote:
> > Don't forget we can mix-and-match C/C++ to some degree
>
>for added portability!
>
>--
>If computer science was a science, computer "scientists" would study what
>computer systems do a
On Wed, 6 Dec 2000, Dan Sugalski wrote:
> What I'm thinking is that we'll have a scoped destruct stack that gets
> pointers to variables that explicitly need destruction, and as we exit
> levels of scope we call the destructors of those variables that need it.
> (They can still be GC'd later to p
At 03:14 PM 12/6/00 -0500, Sam Tregar wrote:
>On Wed, 6 Dec 2000, Dan Sugalski wrote:
>
> > What I'm thinking is that we'll have a scoped destruct stack that gets
> > pointers to variables that explicitly need destruction, and as we exit
> > levels of scope we call the destructors of those variabl
On Wed, 6 Dec 2000, Dan Sugalski wrote:
> >my $new_dog;
> >{
> > my $dog = new Dog;
> > $new_dog = \$dog;
> >}
>
> That would hoist the Dog reference into an outer level of scope--in this
> case the one containing $new_dog. Or so my thinking goes at the moment,
> though th
Simon Cozens wrote:
>
> Oh boy, it's OO syntax nargery time again. *sigh*.
> > I think it would be cool
>
> Good for you. This is internals design; perl6-language is over there --->
> and the "ph33r mY |<" phase is supposed to be over now
> anyway.
Cool! Thanks alot for the useful feedback. Co
At 03:38 PM 12/6/00 -0500, Sam Tregar wrote:
>On Wed, 6 Dec 2000, Dan Sugalski wrote:
>
> > >my $new_dog;
> > >{
> > > my $dog = new Dog;
> > > $new_dog = \$dog;
> > >}
> >
> > That would hoist the Dog reference into an outer level of scope--in this
> > case the one contain
At 12:48 PM 12/6/00 -0800, Nathan Wiger wrote:
> > Good for you. This is internals design; perl6-language is over there --->
> > and the "ph33r mY |<" phase is supposed to be over now
> > anyway.
>
>Cool! Thanks alot for the useful feedback. Comments like this are
>certainly beneficial to the goal
On Wed, 6 Dec 2000, Dan Sugalski wrote:
> Non-refcounting GC schemes are more expensive when they collect, but less
> expensive otherwise, and it apparently is a win for the non-refcount
> schemes.
Which is why GC is intimately tied to DESTROY consideration in terms of
Perl. If we intend to hon
At 03:54 PM 12/6/00 -0500, Sam Tregar wrote:
>On Wed, 6 Dec 2000, Dan Sugalski wrote:
>
> > Non-refcounting GC schemes are more expensive when they collect, but less
> > expensive otherwise, and it apparently is a win for the non-refcount
> > schemes.
>
>Which is why GC is intimately tied to DESTR
At 03:54 PM 12-06-2000 -0500, Sam Tregar wrote:
>On Wed, 6 Dec 2000, Dan Sugalski wrote:
>
> > Non-refcounting GC schemes are more expensive when they collect, but less
> > expensive otherwise, and it apparently is a win for the non-refcount
> > schemes.
>
>Which is why GC is intimately tied to DE
On Wed, 6 Dec 2000, Dan Sugalski wrote:
> Sure, but only objects. (or, to be really paranoid, things referred to)
> Nothing else needs refcounting. All the refcounting code can be isolated in
> the reference creation and deletion code, and we don't have to pay it
> otherwise.
Good point. I hadn
In http://www.mail-archive.com/perl6-internals@perl.org/msg01766.html,
Dan outlined rev 2 of the RFC process, PDD (Perl Design Docs).
Everything seems rather specific to internals - will there be a separate
mechanism in place for all-things non-internal, say, for instance, the format
for a non-in
Bennett Todd <[EMAIL PROTECTED]> writes:
> My own personal favourite for archival format would be to stick with POD
> until and unless we can cons up something even Plainer than POD. I've
> got this dream that someday we'll be able to take something --- perhaps
> based on Damian's Text::Autoforma
On Wed, Dec 06, 2000 at 03:59:32PM -0800, Russ Allbery wrote:
> Bennett Todd <[EMAIL PROTECTED]> writes:
>
> > My own personal favourite for archival format would be to stick with POD
> > until and unless we can cons up something even Plainer than POD. I've
> > got this dream that someday we'll b
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> More importantly, what we're doing is outside Java's area of competence.
> We're writing system-level code here. Java isn't a system-level programming
> language. This isn't a bad thing, but it means it's an inappropriate
> solution to the problem. We
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> [vtable stuff snipped]
> I don't think it's too early to be dealing with the way variables are
> implemented, at least at some level.
I agree; I didn't mean for it to sound like I was saying otherwise.
> Also, just because we do vtables under the ho
Nicholas Clark <[EMAIL PROTECTED]> wrote:
>
> 2 things the above reminds me to watch out for
>
>int32 toInt32()
>
> don't assume anything about integer sizes (or any machine native type sizes
> or precisions, or that floating point can (or can't) preserve integers)
>
> Un
> > Why does string C have to screw everything up?
Nathan Torkington <[EMAIL PROTECTED]> wrote:
> It doesn't. String eval is the escape hatch from a language that can't do
> what you want it to do. As such it's okay for it to be slow--consider it
> incentive to fix the language :-) The runti
> At 07:49 AM 12/6/00 -0800, Daniel Chetlin wrote:
> >Simply deciding that `eval STRING' is "unimplemented" on these
> >theoretical ports and binary compiles is the best idea I've heard yet,
> >but we should remember that `require' is built on `eval STRING'.
I see no reason to ghettoize powerful
On Wed, Dec 06, 2000 at 08:30:06PM -0500, Bradley M. Kuhn wrote:
> > At 07:49 AM 12/6/00 -0800, Daniel Chetlin wrote:
> > >Simply deciding that `eval STRING' is "unimplemented" on these
> > >theoretical ports and binary compiles is the best idea I've heard yet,
> > >but we should remember that `re
On Wed, 6 Dec 2000, Bradley M. Kuhn wrote:
> And, it will make the barrier for entry for new internals hacker lower.
Really? Do you honestly believe there are more Java programmers than C
programmers? Particularily in the Perl development community!
> I would note that if we write in Java, we
> Decisions of GC models rapidly become religious arguments.
The most important argument is: Does a particular
GC model meet the Perl 6 language requirements?
Reference counting fulfills the language requirement
for deterministic destructor calls. (Those
destructors might be freeing non-memor
> This example shows that you can offend all
> "religious" camps and still capitalize on their
> disparate arguments.
Sounds like keeping the holidays of all the religions and but none of
the penances. I like it :-)
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist
39 matches
Mail list logo
