Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
[Re: Giving data about why it's hard to use B:: to port to the JVM]
> Yes, *PLEASE*. Some hard data is always nice, even when (or especially
> when) it's unpleasant to hear.
I won't have "hard numbers", as it is always completely possible that some
On Mon, Dec 11, 2000 at 08:18:05AM -0500, Joshua N Pritikin wrote:
> On Sat, Dec 09, 2000 at 05:06:27AM -0500, [EMAIL PROTECTED] wrote:
> > > Because the Python folks didn't have a problem basing JPython off of
> > > CPython.
> >
> > Actually, this one isn't a good comparison. Python is substant
On Sat, Dec 09, 2000 at 05:06:27AM -0500, [EMAIL PROTECTED] wrote:
> > Because the Python folks didn't have a problem basing JPython off of
> > CPython.
>
> Actually, this one isn't a good comparison. Python is substantially easier
> to parse, and, is a much simpler language. I like Perl becaus
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 05:55 PM 12/7/00 +, Piers Cawley wrote:
> >Dan Sugalski <[EMAIL PROTECTED]> writes:
> > > I think I'd just as soon always call DESTROY in a predicable manner
> > > and not do *anything* perlish at GC time. If nothing else it means
> > > that we do
On Thu, Dec 07, 2000 at 07:07:27PM +, Simon Cozens wrote:
> On Thu, Dec 07, 2000 at 12:24:50PM +, David Mitchell wrote:
> > In a Perl context, I find it hard to believe that reference counting takes
> > up more than tiny fraction of total cycles.
>
> On a vaguely related note, here's the
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> one of the big goals I have is to get everything specified enough that
> someone can produce another version of perl from scratch.
[..]
> The final specs that define those bits of perl's internal behavior that are
> user-visible (like the hooks in the
bkuhn wrote:
> > Why should we center our entire design around C?
Adam Turoff <[EMAIL PROTECTED]> wrote:
> Because Perl is a write-once-run-anywhere platform, and C is the only
> viable way of maintaining Perl support on all of the platforms currently
> supported.
>
> Because most (all?) of
Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> > Why should we center our entire design around C? Sure, the canonical perl6
>
> Because that's what we got. Because that's what we have in the maximal
> number of platforms. Because that's what works.
The design doesn't have to center around
On Thu, Dec 07, 2000 at 10:42:31PM -0500, Bradley M. Kuhn wrote:
> What I seek is perl design documentation that allows someone to take the set
> of PDD's and reimplement perl in another language.
What will aid Perl reimplementations are the PDDs. C-Centrism in the
PDDs is a moot point.
> The
"Bradley M. Kuhn" wrote:
>
> > On Wed, 6 Dec 2000, Bradley M. Kuhn wrote:
> >
> > > And, it will make the barrier for entry for new internals hacker lower.
>
> Sam Tregar <[EMAIL PROTECTED]> wrote:
>
> > Really? Do you honestly believe there are more Java programmers than C
> > programmers? P
On Fri, Dec 08, 2000 at 01:17:01PM +, Nicholas Clark wrote:
> We seem to be arguing about the best method for making it *im*possible
> to use anything but the initially-chosen-implementation language to
> implement perl. This feels like a bad thing.
I don't see that; I see that we're all agre
On Fri, Dec 08, 2000 at 10:36:48AM +, Simon Cozens wrote:
> On Thu, Dec 07, 2000 at 10:11:11PM -0500, Bradley M. Kuhn wrote:
> > I believe strongly that we need to make sure the design does not become so C
> > specific so as to leave us where perl5 has left us: "No C compiler on your
> > platf
On Thu, Dec 07, 2000 at 10:42:31PM -0500, Bradley M. Kuhn wrote:
> Since we are starting from scratch, why not make these things possible if it
> isn't too hard? And, I don't think it is, if we are simply mindful to "not
> be C specific" as we design.
I think everyone's agreed this, many times o
On Thu, Dec 07, 2000 at 10:11:11PM -0500, Bradley M. Kuhn wrote:
> I believe strongly that we need to make sure the design does not become so C
> specific so as to leave us where perl5 has left us: "No C compiler on your
> platform? Sorry!".
Huh? There are platforms have Java VMs but not C compi
At 06:01 PM 12/7/00 +, Piers Cawley wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
> > At 01:20 PM 12/7/00 +, David Mitchell wrote:
> > >Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > >
> > > > print $foo[0];
> > > > is
> > > >foo->get_string[UTF_8](ARRAY, 0);
> > > > while
> > > >
At 10:46 PM 12/7/00 -0500, Bradley M. Kuhn wrote:
>John Porter <[EMAIL PROTECTED]> wrote:
>
> > Almost. You're potentially taking away Perl6, which is vaporware.
> > I wonder: In what order will the following exist on Handheld Device
> > Foo:
> >
> > - C
> > - C++
> > - Java
> >
On Thu, Dec 07, 2000 at 10:23:55PM -0500, Bradley M. Kuhn wrote:
> However, the JVM is a powerful environment for generalized bytecode and for
> allowing bytecode of different languages to communicate.
So's Microsoft vaporware ".NET platform". And the second version
of that bytecoded runtime wi
John Porter <[EMAIL PROTECTED]> wrote:
> Almost. You're potentially taking away Perl6, which is vaporware.
> I wonder: In what order will the following exist on Handheld Device
> Foo:
>
> - C
> - C++
> - Java
> - Perl6
I know of at least one hand-held on the market (Po
Simon Cozens <[EMAIL PROTECTED]> wrote:
> It seems like everyone has their axes to grind on this one: Bradley thinks
> the world must be built in Java,
I don't believe that. There has been a misunderstanding, and I apologize if
I didn't communicate that effectively.
I don't really care *that*
On Thu, Dec 07, 2000 at 10:23:55PM -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 r
> > > 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'.
> On Wed, Dec 06, 2000
> On Wed, 6 Dec 2000, Bradley M. Kuhn wrote:
>
> > And, it will make the barrier for entry for new internals hacker lower.
Sam Tregar <[EMAIL PROTECTED]> wrote:
> Really? Do you honestly believe there are more Java programmers than C
> programmers? Particularily in the Perl development commu
m perl6-internals-design (or whatever) with bits marked "We need
> to remember to think about this more!", and making sure those bits are covered
> on the meta-design, with an option on learning about the topic and writing a
> short summary for everyone to gain from. It would
At 07:02 PM 12/7/00 +, Simon Cozens wrote:
>On Wed, Dec 06, 2000 at 03:11:33PM -0500, Dan Sugalski wrote:
> > >I'm in favour of the exact opposite: an AV is "just" an SV-alike vtable
> > >with array methods instead of scalar methods and a pointer to some
> > >storage, (probably an array of SVs
Simon Cozens wrote:
>
> Great. When it comes down to it, what are you doing here?
Excellent question.
--
John Porter
On Thu, Dec 07, 2000 at 03:40:37PM -0500, John Porter wrote:
> When it comes right down to it, the likelihood that I personally
> will contribute to the core is vanishingly small, regardless of
> language.
Great. When it comes down to it, what are you doing here?
> I wonder: In what order will
Jarkko Hietaniemi wrote:
>
> You seem hell-bent to gain popularity and support, don't you.
Do I? "Hell-bent"?
When it comes right down to it, the likelihood that I personally
will contribute to the core is vanishingly small, regardless of
language. So, I guess you can defend your own choice o
On Thu, Dec 07, 2000 at 07:42:26PM +, Nicholas Clark wrote:
> What was Sapphire's implementation language? What were its lessons?
See http://www.perl.com/pub/2000/09/sapphire.html
--
Hildebrant's Principle:
If you don't know where you are going, any road will get you there.
On Thu, Dec 07, 2000 at 02:33:53PM -0500, John Porter wrote:
> I'd say, screw 'em if they don't have a C++ compiler.
No.
--
"The best index to a person's character is a) how he treats people who can't
do him any good and b) how he treats people who can't fight back."
-- Abigail Van Buren
On Thu, Dec 07, 2000 at 02:33:53PM -0500, John Porter wrote:
> Simon Cozens wrote:
> > On Thu, Dec 07, 2000 at 11:22:35AM -0500, John Porter wrote:
> > > [C++]
> >
> > > It's nearly as portable,
> >
> > Uhm. Is this actually true?
>
> I don't know. Sounds reasonable! :-)
>
> Aside from lam
Sam Tregar wrote:
>
> Which also brings up another point - choosing anything but C is likely to
> have a direct impact on our existing userbase. I have a suggestion - if a
> system compiled and ran Perl 5 then it should be able to compile and run
> Perl 6. No upgrades required.
The Backwards C
On Thu, Dec 07, 2000 at 02:33:53PM -0500, John Porter wrote:
> Simon Cozens wrote:
> > On Thu, Dec 07, 2000 at 11:22:35AM -0500, John Porter wrote:
> > > [C++]
> >
> > > It's nearly as portable,
> >
> > Uhm. Is this actually true?
>
> I don't know. Sounds reasonable! :-)
What did Chip lear
On Thu, 7 Dec 2000, Simon Cozens wrote:
> On Thu, Dec 07, 2000 at 11:22:35AM -0500, John Porter wrote:
> > [C++]
>
> > It's nearly as portable,
>
> Uhm. Is this actually true? C runs pretty much anywhere.
>
> Are there any non-fragile implementations of C++ yet?
Which also brings up another poin
Simon Cozens wrote:
> On Thu, Dec 07, 2000 at 11:22:35AM -0500, John Porter wrote:
> > [C++]
>
> > It's nearly as portable,
>
> Uhm. Is this actually true?
I don't know. Sounds reasonable! :-)
Aside from lame-o solutions like C-front and cross-compiling,
I'd say, screw 'em if they don't ha
> often. What the *hell* is wrong with modulo?
It does sort of stand out, doesn't it...floating point divide?
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
On Thu, Dec 07, 2000 at 12:24:50PM +, David Mitchell wrote:
> In a Perl context, I find it hard to believe that reference counting takes
> up more than tiny fraction of total cycles.
On a vaguely related note, here's the flat profile from gprof run
cumulatively on the test suite. (I haven't
On Wed, Dec 06, 2000 at 03:11:33PM -0500, Dan Sugalski wrote:
> >I'm in favour of the exact opposite: an AV is "just" an SV-alike vtable
> >with array methods instead of scalar methods and a pointer to some
> >storage, (probably an array of SVs) and likewise an HV. That would allow
> >(array->leng
On Thu, Dec 07, 2000 at 11:22:35AM -0500, John Porter wrote:
> [C++]
> It's nearly as portable,
Uhm. Is this actually true? C runs pretty much anywhere.
Are there any non-fragile implementations of C++ yet?
> nearly as fast,
Why have nearly as fast, when you can have as fast?
> and WAY WAY
On Thu, Dec 07, 2000 at 12:06:36PM +, Nicholas Clark wrote:
> > I think that that would be a 'courageous' decision.
>
> Making decisions now that make it hard to use anything other than 1 compiler
> are as wise as decisions that make it hard to use anything other than one
> implementation lan
At 05:55 PM 12/7/00 +, Piers Cawley wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
> > I think I'd just as soon always call DESTROY in a predicable manner
> > and not do *anything* perlish at GC time. If nothing else it means
> > that we don't have to worry about having a valid perl context
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 01:20 PM 12/7/00 +, David Mitchell wrote:
> >Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >
> > > print $foo[0];
> > > is
> > >foo->get_string[UTF_8](ARRAY, 0);
> > > while
> > >print $foo
> > > is
> > >foo->get_string[UTF_8](SCALAR);
Dan Sugalski <[EMAIL PROTECTED]> writes:
> I think I'd just as soon always call DESTROY in a predicable manner
> and not do *anything* perlish at GC time. If nothing else it means
> that we don't have to worry about having a valid perl context handy
> when the GC runs. (Since threading the thing i
On Thu, Dec 07, 2000 at 11:24:06AM -0500, Dan Sugalski wrote:
> I think I'd just as soon always call DESTROY in a predicable manner and not
> do *anything* perlish at GC time. If nothing else it means that we don't
> have to worry about having a valid perl context handy when the GC runs.
> (Sin
At 01:20 PM 12/7/00 +, David Mitchell wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > print $foo[0];
> > is
> >foo->get_string[UTF_8](ARRAY, 0);
> > while
> >print $foo
> > is
> >foo->get_string[UTF_8](SCALAR);
>
>Just to clarify:
>
>does the get_string method in an AV's
On Wed, Dec 06, 2000 at 08:28:14PM -0500, Bradley M. Kuhn wrote:
> Whether or not it is slow is not my concern.
Speed isn't (necessarily) the problem, although I'd prefer it if Perl wasn't
slow. *Size* is the problem. On-the-fly evaluation requires a compiler and its
associated environment, and t
At 11:17 AM 12/7/00 +, Piers Cawley wrote:
>Buddha Buck <[EMAIL PROTECTED]> writes:
> > It seems to me that there are three types of thingies[1] we are
> > concerned about, conceptually:
> >
> >
> > A) Thingies with no DESTROY considerations, which don't need refcounts.
> > B) Thingies with DE
Nicholas Clark wrote:
>
> But fflush(NULL) is, and we still seem to run
> into that one on one current platform
Amazingly, there are still things in supposedly ANSI-conformant
implementations that are done wrong. free(0) is supposed to be
a safe no-op; but on certain compilers, we get a crash.
Piers Cawley wrote:
>
> > And, it will make the barrier for entry for new internals hacker
> > lower.
>
> Err. How do you get to that conclusion? The thing that really stops me
> mucking about with perl's internals is the fiendish complexity of said
> internals. Changing the programming language
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> print $foo[0];
> is
>foo->get_string[UTF_8](ARRAY, 0);
> while
>print $foo
> is
>foo->get_string[UTF_8](SCALAR);
Just to clarify:
does the get_string method in an AV's vtable do an indexing lookup,
grab the relevant SV pointer, then call
(whoops, correcting my own post!):
> sva->refcount=0;
> sva->refcount++; // these first 2 combined if we get the implemention right
> svb->refcount=0;
> svb->refcount++; // ditto
sva->refcount++;
> ...
> if (--sva->refcount == 0) ... // branch not taken
> if (--svb->refcount == 0) ... // branch
On Thu, Dec 07, 2000 at 01:22:08PM +0100, Roland Giersig wrote:
> How about a two-step requirement?
>
> 1) Native compiler must support ANSI-C.
>
> 2) If 1) doesn't hold, gcc can be required, which fulfills ANSI-C.
strictly and really pedant point no it doesn't quite, as ANSI specifies
the comp
> There's evidence in the
> literature that switching from reference counting to a more sophisticated
> GC scheme can also save us 5-10% in CPU overhead. (Though that's not a
> guarantee--LISPlike languages likely have different GC performance
> characteristics than perl does)
[warning: vague
Dan Sugalski wrote:
> 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 m
On Thu, Dec 07, 2000 at 10:54:09AM +, Piers Cawley wrote:
> "Bradley M. Kuhn" <[EMAIL PROTECTED]> writes:
> > Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > > 2) GCC produces slow code on all platforms where there's an
> > >alternative.
> >
> > This is likely going to change with the releas
Buddha Buck <[EMAIL PROTECTED]> writes:
> 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
> > >
"Bradley M. Kuhn" <[EMAIL PROTECTED]> writes:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> However, I don't think we should dismiss it out of hand because people don't
> do a lot of systems programming C. some of the things we are going to build
> for C (if that's what we pick), are already there
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
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
> 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
> > 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
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
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
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
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
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
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
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 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
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
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
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
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:
> 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 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
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.
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
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 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
bits marked "We need
to remember to think about this more!", and making sure those bits are covered
on the meta-design, with an option on learning about the topic and writing a
short summary for everyone to gain from. It would probably also need updating
when we settle one of the issues on
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 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
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
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 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
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
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 everythin
> 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
> 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
calar value as Unicode string
ASCIIString toString() # returns the scalar value as an ASCII string
C++ implementors will have fun with names that assume one can overload on
return type.
These won't be the only things to be wary of. Presumably a list of such
guidelines are someth
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
At 11:12 PM 12/5/00 -0500, Bradley M. Kuhn wrote:
>Simon Cozens <[EMAIL PROTECTED]> wrote:
> > Of the suggestions that have been advanced so far, four are worthy of
> > more consideration: C, C++, Java and a specially-designed Perl
> > Implementation Language. (PIL)
>
> > Java is portable and giv
Bradley M. Kuhn writes:
> > Java is portable and gives us OO, but it's slow and ugly.
>
> I am probably the biggest proponent of the "use Java to implement Perl"
> camp.
Java is only somewhat portable.
> One concern that I have about the data structure design thus far (and I
> believe I wrote a
Simon Cozens <[EMAIL PROTECTED]> wrote:
> Patches welcome.
Well, this isn't a patch, but if you really meant patches literally and not
figuratively, I can provide one if you let me know. ;)
> Of the suggestions that have been advanced so far, four are worthy of
> more consideration: C, C++, J
Patches welcome.
=head1 Introduction
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.
It's completely unofficial, it's completely m
95 matches
Mail list logo
