On Tue, 5 Dec 2000, Steve Fink wrote:
> David Grove wrote:
>
> > Also, as far as documentation goes, I think it _should_ be written by
> > apprentices, so that non-masters can understand it too. That's always been
>
> Except it's a particular duty that nobody really likes to perform. Which
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, 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
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
Kirrily Skud Robert <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 05, 2000 at 11:28:31AM -0800, Nathan Wiger wrote:
> >
> > Anyways, that's just one suggestion. Do I have any idea where to find
> > these mythical people? No, unfortunately. Perhaps some feelers on
> > newsgroups might be a good p
On Tue, Dec 05, 2000 at 10:00:50PM +, Nick Ing-Simmons wrote:
> B. The "master" / "apprentice" relationship is just that - it depends
>how the people in question relate. As a potential "master" I am all
>too aware that I am not skilled in teaching - usually because I don't
>know w
other languages are great. they are a source of features to
steal^Wborrow.
INTERCAL
except maybe intercal
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 03:08 PM 12/6/00 -0500, Bryan C. Warnock wrote:
>On Wed, 06 Dec 2000, Dan Sugalski wrote:
> > Well, until Larry releases the spec, just about everything else is frozen,
> > though we can certainly expand the PDD stuff to include the standard
> > library, documentation, and QA stuff. (It seems a
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, 06 Dec 2000, Dan Sugalski wrote:
> Well, until Larry releases the spec, just about everything else is frozen,
> though we can certainly expand the PDD stuff to include the standard
> library, documentation, and QA stuff. (It seems a tad premature to be
> proposing language changes when
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
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
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
> >Open Source Writers Group (http://oswg.org/) is a good starting point.
> >I'm subscribed to their mailing list. I can think of a couple of
other
> >good places to try, too, but they're a bit politically incorrect to
> >mention in this context :-/
>
> Who on earth would be considered poli
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
Kirrily Skud Robert wrote:
>
> Open Source Writers Group (http://oswg.org/) is a good starting point.
> I'm subscribed to their mailing list.
This is really cool. Should we consider posting an announcement to this
website for potential docs people? Or is it still premature to do
something like
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
http://www.salon.com/tech/feature/2000/12/06/bad_computers/index.html
And no, open source software is *not* immune.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PRO
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
48 matches
Mail list logo
