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
I would like to do this, but I think its a bigger job than you imagine, and...
"I tend towards insanity from time to time. Good thing its only perl." (you can
quote me)
(It comes from stresses developing sysadm apps around the single largest depository of
human wealth. They actually smoth
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
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
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 everything up?
It doesn't.
> 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
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
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
94 matches
Mail list logo
