--- Simon Cozens [EMAIL PROTECTED] wrote:
On Mon, Sep 10, 2001 at 11:26:03AM -0700, Benjamin Stuhl
wrote:
It's not a prioirty, but it's so much easier to walk
the
correct path from the start. Since it's all Parrot,
it's even easier.
Hear, hear! I remember the pain in 5.005_5* of
At 05:25 AM 9/11/2001 -0700, Benjamin Stuhl wrote:
However, before I do this, I would like to bring up
the question of prefixes once again. Do we really need a 7
letter, mixed-case prefix (Parrot_)?
Externally exposed, yes.
That's not to say that the programmer working inside the core needs to
Simon Cozens writes:
I am in two minds here. I want to have Parrot_... prefices on
functions even if they're *not* completely necessary /pour
encourager les autres/. However, I don't want to go the way of
opening up everything in a public API righht now, because once
you've exported a
On Monday 10 September 2001 12:58 pm, Nathan Torkington wrote:
Here's my Official Word. Right now it's too early to know whether
building perl6's runtime to also support other languages will impact
perl6's speed or size. We also have faced skepticism about the whole
effort from other
On Mon, Sep 10, 2001 at 10:58:33AM -0600, Nathan Torkington wrote:
let's assume that Parrot will only officially be part of the Perl project,
and focus on writing more Parrot code instead of arguing about
namespaces.
What He Said.
And in addition - why are we worrying about namespace
On Monday 10 September 2001 01:08 pm, Simon Cozens wrote:
And in addition - why are we worrying about namespace collision RIGHT NOW?
Sure, when Parrot can be embedded, then we should ensure that our names
aren't going to clash. But who in their right minds is going to embed
Parrot in anything
At 01:20 PM 9/10/2001 -0400, Bryan C. Warnock wrote:
On Monday 10 September 2001 01:08 pm, Simon Cozens wrote:
And in addition - why are we worrying about namespace collision RIGHT NOW?
Sure, when Parrot can be embedded, then we should ensure that our names
aren't going to clash. But who in
Bryan C. Warnock writes:
It's not a prioirty, but it's so much easier to walk the correct path from
the start. Since it's all Parrot, it's even easier.
I agree. How about this: when the code is available (i.e., this
afternoon), why don't you sit down with whoever else feels
passionately
Erk, we seem to be muddling around in that great grey area between what is
Parrot and what is Perl.
Parrot is striving to be a common backend for multiple scripting languages,
of which one is Perl 6, no? And, of course, to adequately test Parrot, you
need to concurrently develop Perl 6, yes?
Bryan C. Warnock [EMAIL PROTECTED] wrote:
Erk, we seem to be muddling around in that great grey area between what is
Parrot and what is Perl.
Yes, which leads me on to think...
(With my maintainer of the Coding PDD hat on)
Presumably we have to decide what bits of code have a Parrot_
At 10:29 AM 9/10/2001 -0400, Bryan C. Warnock wrote:
Erk, we seem to be muddling around in that great grey area between what is
Parrot and what is Perl.
Parrot is striving to be a common backend for multiple scripting languages,
of which one is Perl 6, no? And, of course, to adequately test
On Monday 10 September 2001 11:16 am, Dan Sugalski wrote:
No. We don't need perl to test the interpreter. Parser and compiler, yes,
interpreter no.
The code that we are writing in assembler is Parrot opcode that we would
expect a Perl parser and compiler to spit out. (That's all I'm
Bryan C. Warnock writes:
Like I said, just things to keep in mind. There's a slight difference
between designing and coding Parrot as an interpreter backend, and coding it
as a backend to Perl that other languages can use. (I'm in favor of the
latter, though public opinion seems to favor
13 matches
Mail list logo
