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 don't have to
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 because it
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
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 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 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
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
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
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 agreed
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
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
platform?
"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 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 compiled
(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 taken,
if
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 DESTROY methods,
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
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 is a
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 handy
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
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-length)()
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
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
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 have a
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 learn from Topaz?
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
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 lame-o solutions like
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 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.
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 of
Simon Cozens wrote:
Great. When it comes down to it, what are you doing here?
Excellent question.
--
John Porter
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) and
o 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 it, with a brief note
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 at 08:30:06PM
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 remember that
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
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
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
- Perl6
I
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 something useful for someone to maintain on the meta-design
list. (Is maintaining
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 more
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 Ceval 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 Ceval 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 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 XS wrapper for
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 may
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
d "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 it, with
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 wrapper for
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 just
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 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.
I don't think
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 pick
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 variables that
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 there may be
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 |ewl dr3am 5inta" phase is supposed to be over now
anyway.
Cool! Thanks alot for the useful
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 containing $new_dog. Or so my
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 DESTROY
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 DESTROY
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't
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 hood
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)
Why does string Ceval 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 runtime
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 `require' is
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
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
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 my opinion, it's
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++, Java
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 an RFC
70 matches
Mail list logo
