On Tue, Jul 09, 2002 at 09:50:26PM -0400, Chip Salzenberg wrote:
Based on what I rememeber from the long threads about this,
>3. Is C<%MY> intended to reflect the PAD?
loosely speaking yes.
>
> 3a. If so, how can one distinguish among the e.g. many C
> variables declared within
"Clark C . Evans" wrote:
> So, I propose that Parrot supports both of these attitudes
> of reasoning by using a flag. Initially, all strings
> are 'mutable'.
I concur with Clark. What he's proposing is (it seems to me)
nothing more than a "read-only" flag, and that's as
immutable as a variab
umm... has anyone else noticed that pdd02 in the distribution (0.4)
is spouged, and that pdd03 is completely missing?
--
John Douglas Porter
__
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
I'm following this list only for a very short time now, and I don't have very much
programming experience, so tell me if all this is pure nonsense.
But isn't this partly addressed with COW? The way I understood Copy On Write, it means
that if you "copy" a string, only some pointers are copied and
Florian Haeglsperger wrote:
> But isn't this partly addressed with COW?
> . . .
> Thus I don't see a very big performance win in introducing mutable
> strings.
Good point.
But some people maintain that there could be a need for truly
"constant" strings, that should never be modified, and any
a
At 2:30 PM -0700 7/9/02, John Porter wrote:
>Garrett Goebel wrote:
>> John Porter wrote:
>> > Not to beat on Dan (or anyone else), but for the sake of those
>> [...]
>>
>> Please don't beat on Dan... ;)
>
>I'm not!
Nope, he isn't.
Warnings and concerns based on technical merits and past expe
Dan Sugalski wrote:
> These 'add-on' bytecode interpreters don't get any special
> consideration in the core. That means they *can* have:
>
> *) A custom bytecode loader to translate their bytecode format
>to ours, or something we can use
> *) As many custom PMC classes as they want
> *) D
At 8:35 PM -0700 7/9/02, John Porter wrote:
>Dan Sugalski wrote:
>> John Porter wrote:
>> > Why is "left side wins" insufficient?
>>
>> Well, perl 5 is apparently not left side wins for overloading, which
>> is enough.
>
>Mmmm. Have a good example handy?
I'll have to go dig one up. Damian hi
At 7:34 AM -0700 7/10/02, John Porter wrote:
>Florian Haeglsperger wrote:
>> But isn't this partly addressed with COW?
>> . . .
>> Thus I don't see a very big performance win in introducing mutable
>> strings.
>
>Good point.
>
>But some people maintain that there could be a need for truly
>"co
At 9:50 PM -0400 7/9/02, Chip Salzenberg wrote:
>3. Is C<%MY> intended to reflect the PAD?
Yes.
> 3a. If so, how can one distinguish among the e.g. many C
> variables declared within the current function?
One pad per block, rather than per sub.
--
Dan Sugalski wrote:
> What we're
> doing is assuming we don't know and letting the variables decide
> whether they'll care. Perl's will, though other languages can decide
> differently.
Letting the variables decide?
So, we take a poll of all the arguments, and ask each one
which they think ou
Dan Sugalski wrote:
> I'm not sure that the place to enforce read-onlyness is at the
> string/buffer level. Doing it at the PMC level is more likely the
> right place to do it.
Yes; but what about non-PMC variables?
--
John Douglas Porter
__
On Wed, Jul 10, 2002 at 10:17:47AM -0700, John Porter wrote:
>
> Dan Sugalski wrote:
> > Heh. I never expected to have to dust off my trig skills when I
> > started this. If I need to dig out the calculus books, I think I'll
> > just go run screaming...
>
> Not to worry. There's no trig invo
Would I be out of line to request that people edit their email
headers so that replies only go to the list?
I'm tired of getting two (or more) copies of everything on
any thread I've posted in.
Thanks,
John Douglas Porter
__
Do You Yahoo!?
Sign u
At 10:21 AM -0700 7/10/02, John Porter wrote:
>Dan Sugalski wrote:
>> I'm not sure that the place to enforce read-onlyness is at the
>> string/buffer level. Doing it at the PMC level is more likely the
>> right place to do it.
>
>Yes; but what about non-PMC variables?
Generally speaking, there
At 10:17 AM -0700 7/10/02, John Porter wrote:
>Dan Sugalski wrote:
>> What we're
>> doing is assuming we don't know and letting the variables decide
>> whether they'll care. Perl's will, though other languages can decide
>> differently.
>
>Letting the variables decide?
>So, we take a poll of a
# New Ticket Created by Simon Glover
# Please include the string: [netlabs #788]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=788 >
This patch fixes a number of off-by-one errors in array.pmc, and adds a
few more t
# New Ticket Created by Simon Glover
# Please include the string: [netlabs #789]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=789 >
stack_chunk is now Stack_Chunk...
Simon
--- sub.c.old Wed Jul 10 14:53:24 2002
# New Ticket Created by Simon Glover
# Please include the string: [netlabs #790]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=790 >
Self-explanatory.
Simon
--- MANIFEST.oldWed Jul 10 14:43:48 2002
+++ MAN
Dan Sugalski wrote:
> John Porter wrote:
> > but what about non-PMC variables?
>
> Generally speaking, there aren't any. Everything else (in this case
> the buffer/string things) is for internal use only. Languages aren't
> supposed to expose strings directly.
Languages are only supposed to e
At 02:13 PM 7/10/2002 -0700, John Porter wrote:
>Dan Sugalski wrote:
> > John Porter wrote:
> > > but what about non-PMC variables?
> >
> > Generally speaking, there aren't any. Everything else (in this case
> > the buffer/string things) is for internal use only. Languages aren't
> > supposed to
On Wed, 10 Jul 2002, Melvin Smith wrote:
> At 02:13 PM 7/10/2002 -0700, John Porter wrote:
>
> >Dan Sugalski wrote:
> > > John Porter wrote:
> > > > but what about non-PMC variables?
> > >
> > > Generally speaking, there aren't any. Everything else (in this case
> > > the buffer/string things) i
On Wednesday 10 July 2002 02:39 pm, Melvin Smith wrote:
>
> Since Perl vars type-morph themselves, Perl will use PMC types everywhere
> that there is an exposed interface. Internally you could use an I/S/N
> register.
>
> I see no reason why
>
> foreach my $i (@nums) {
> ...
> }
>
> should not u
Okay, one of the outstanding problems we've had is in adding the
system stack to the root set. A number of depressingly unpleasant
solutions have been proposed (most of 'em by me :) but they're all
hackish and expensive in the common case, which is not needing to GC
anything.
Turns out, thoug
At 04:24 PM 7/10/2002 +0100, [EMAIL PROTECTED] wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> > At 9:50 PM -0400 7/9/02, Chip Salzenberg wrote:
> > >3. Is C<%MY> intended to reflect the PAD?
> >
> > Yes.
>
>Hey! How's this for a scary thought:
>
>$continuation.the_pad
>
>I'll get my
Chip Salzenberg wrote in perl.perl6.language :
> In (re?)examining the Apocalypses, I've found something that confuses me a
> bit. A2 refers to C as a "pseudopackage" and says:
>
> __LINE__ becomes MY.line
> __FILE__ " MY.file
>
[...]
>
> With regard to C:
>
>2. What
At 4:24 PM +0100 7/10/02, [EMAIL PROTECTED] wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>> At 9:50 PM -0400 7/9/02, Chip Salzenberg wrote:
>> >3. Is C<%MY> intended to reflect the PAD?
>>
>> Yes.
>
>Hey! How's this for a scary thought:
>
>$continuation.the_pad
What's that suppos
At 10:12 PM + 7/10/02, Rafael Garcia-Suarez wrote:
>Chip Salzenberg wrote in perl.perl6.language :
>> In (re?)examining the Apocalypses, I've found something that confuses me a
>> bit. A2 refers to C as a "pseudopackage" and says:
>>
>> __LINE__ becomes MY.line
>> __FILE__
Nicholas Clark:
# On Wed, Jul 10, 2002 at 10:17:47AM -0700, John Porter wrote:
# >
# > Dan Sugalski wrote:
#
# > > Heh. I never expected to have to dust off my trig skills when I
# > > started this. If I need to dig out the calculus books, I
# think I'll
# > > just go run screaming...
# >
# >
At 04:34 PM 7/10/2002 -0600, Luke Palmer wrote:
>On Wed, 10 Jul 2002, Melvin Smith wrote:
>
> > At 02:13 PM 7/10/2002 -0700, John Porter wrote:
> >
> > >Dan Sugalski wrote:
> > > > John Porter wrote:
> > > > > but what about non-PMC variables?
> > > >
> > > > Generally speaking, there aren't any.
# New Ticket Created by "Sean O'Rourke"
# Please include the string: [netlabs #791]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=791 >
This patch adds several ops that exist in the vtables, and seem useful,
but aren't
# New Ticket Created by "Sean O'Rourke"
# Please include the string: [netlabs #792]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=792 >
This patch does the following:
- add defined() to PerlUndef
- add neg(PMC) to Per
At 10:38 PM 7/10/2002 -0500, via RT wrote:
># New Ticket Created by "Sean O'Rourke"
># Please include the string: [netlabs #791]
># in the subject line of all future correspondence about this issue.
># http://bugs6.perl.org/rt2/Ticket/Display.html?id=791 >
>
>
>This patch adds several ops that e
On Wednesday 10 July 2002 08:18 pm, Melvin Smith wrote:
> I was referring to the above situation where a lexical might be optimized
> away without being stored in a pad (for %MY).
I would *hope* %MY is only modified at compile-time. I wouldn'd be upset if
Perl ignored my attempts to access %MY a
34 matches
Mail list logo
