Re: Worst-case GC Behavior?
> Since we're never freeing any memory, it continually is allocating a block > of size 56 (memory pool) + 1 (character) from the underlying system api. Note that Parrot_alloc_new_block will allocate a minimum of DEFAULT_SIZE (set in config.h; currently 32768), so this situation is not quite as bad as it first appears. > Each time through the array, it has to alloc a PMC header. When we > allocate the header, we store it into P0, and the old header is > essentially freed. > > The next time through the loop, entries_in_pool is 0, and it triggers > alloc_more_string_Headers, and a dod run. This finds the PMC we just > freed, and uses it. Repeat. Each time through the loop, it triggers a dod > run. As another example, doing a 5000-generation run of life.pasm ends up on my system with numbers like: 5000 generations in 91.883605 seconds. 54.416672 generations/sec A total of 32768 bytes were allocated A total of 130932 DOD runs were made A total of 10930 collection runs were made Copying a total of 0 bytes There are 81 active Buffer structs There are 256 total Buffer structs In other words, each generation is causing an average of 26 DOD runs. This code does not use PMCs, but string headers exhibit the same problem. Clearing S0 to S14 to zero after the initialisation code, which makes 15 additional free string headers available for the rest of the program, reduces the number of DOD runs by about 15000. One option might be a threshold - if, after the DOD run, there is still less than N headers available, allocate more even though we can satisfy the immediate requirement. This would improve performance by reducing the number of DOD runs, but at the cost of additional memory - a classic tradeoff! -- Peter Gibbs EmKel Systems
COW for strings
I've been thinking about this a bit, especially as I play catchup with a few weeks of p6i mail. Here's my current thinking. 1) COW is useful and trivial in those cases where the original string data is immobile. Constants, for example, or mmapped files. $foo = "bar"; $foo _= "baz"; 2) COW is mildly useful in those cases where two or more strings point to the same moveable string data, and one might end up changing later. $foo = <>; $bar = $foo; chomp $bar; 3) COW is a big pain when we have pointers into the middle of string data pointed to by other things. $foo = $bar x 10; $baz = substr($bar, 20, 30); Case #1 requires no extra effort on the part of the GC, and the string mutating functions. (And since we seem to be mostly immutable strings, that's not too many places) Case #2 requires the complicity of the garbage collector, so when it moves data it can update multiple pointers. I'm not sure this is worth the overhead in the GC, but I could make a case for it. Case #3 is, honestly, more trouble than it's likely worth to support at the string level. I can see doing it with PMCs (where you have a pointer to someone else's string buffer along with an offset and length stored off the PMC somewhere) So anyway, I'm not thinking COW will be worth the hassle in any but case #1. If anyone would care to write the code to prove me wrong, that's keen with me, but I don't want any patches in the repository without good proof. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Avoiding the deadlands
Okay, we're finally hitting the DOD sweeps, and they're starting to cause some trouble. As I see it there are a few ways we can keep embryonic PMCs and Buffers from getting collected before they're fully created and anchored: 1) Set the immortal flag on them until they're fully created 2) Set some sort of partially immortal flag on them 3) Push 'em onto the stack as soon as they're allocated 4) Disable DOD when its inconvenient I think we can discard #4 pretty much right off the bat. We do that too much and we'll find ourselves almost never doing a DOD run. Ick. #3 is interesting, but the downside is that we end up spending a fair amount of time twidding with the stack on every PMC allocation (or a good number of them) for those rare occasions when we actually have a problem. #1 is almost OK, but it's got leakage issues. If something throws an exception without properly cleaning up, well... bang. Or leak. Or something. So, I think #2 is the way to go. We'll add a new flag, (BUFFER|PMC)_stay_of_execution_FLAG or something, that gets added to allocated PMCs and Buffers. It'll be treated the same way as the constant/immortal flag is treated for DOD purposes, with one difference--there'll be an op which specifically clears the flags. Since the flag is *not* valid to be set across ops, we're fine. Only those functions that *must* set it will, and they are also required to make sure the stay_of_execution_count interpreter variable is set to the proper number (or at least large enough) on abnormal exit. (That way we can keep the flag clearing op from actually running if there's no reason) Make sense to everyone? -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl 5 to Parrot
At 11:12 AM +0100 1/2/70, James A Duncan wrote: >Morning (BST) all, > >I've started work on B::Parrot, which is a Perl 5 to Parrot >translation engine. Its very basic at the moment, but I've got it >successfully translating things like: > >my $perliv = 10; >my $perlpv = "\n"; >print $perliv; >print $perlpv; > >into working, assemble-able parrot code. Before I go any further on >this crack-fuelled project is there anything I should be aware of? >Are others working on this? Have I done far too much crack smoking >to consider doing something like this now? I think what you're doing makes perfect sense, and it's a good way to go. It should allow for all programs that are essentially static by CHECK time to be run on Parrot. (Yes, this leaves out runtime requires, do file, and string evals, but that's a reasonably small fraction of the programs out there. It's not sufficient as a general-purpose, long term solution, but it's a dandy one for the short to medium term. By all means, please continue, and if there are things missing from Parrot that'll make it easier (well, OK, besides the known "we have no lexicals, globals, hashes, and arrays" thing :) let me know. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: PMCs requiring a 'set' dest register?
At 5:06 PM -0500 3/31/02, Michel J Lambert wrote: >A second approach is to throw out this weird transmogrifying class stuff, >and just construct a new PMC of the appropriate type to put into the >destination register. Why would we *ever* care what's in the destination >register, since it never gets it's vtable methods called. That's not true. The destination needs its set method called. Otherwise tying/overloading won't work right. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl 5 to Parrot
At 6:07 PM -0500 4/4/02, Melvin Smith wrote: >I also remember there was work already in progress, Simon Cozens mailed >out a tokenizer and I recall Damian Conway saying he was going to deliver >a parser (maybe I'm confused as I often am)? I assume this could be reused, >else we end up with 2 architectures of compiler for Perl5 and Perl6. Damian's not working on the perl 6 parser, and never was. Dunno where the assumption that he was got started. >Who exactly is the pumpking for the Perl(tm) compilers at this time? Nobody. That should change shortly, I think. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [APPLIED] core key support
At 12:32 PM -0800 4/2/02, Steve Fink wrote:
>With the following comment:
>
> - Changes KEY to contain a KEY_PAIR* instead of a KEY_PAIR**
This patch is a cool thing, and I'm very glad it's in. Getting hashes
working should be pretty straightforward soon.
One thing for the next round of patches. Keys should be:
struct Key {
KEY_TYPE type;
union {...} cache;
struct Key *next_key;
}
i.e. a linked list. This way pieces of large key chains can be taken
piece by piece without having to build a new key struct every time.
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: PMCs requiring a 'set' dest register?
At 10:25 AM -0500 4/2/02, Jason Gloudon wrote: >On Tue, Apr 02, 2002 at 01:33:59AM -0500, Michel J Lambert wrote: > >> If instead, registers are aliased onto traditional memory variables, such >> that a PMC pointed to by a register is *also* pointed to by a stash >> somewhere, then it's a bit harder. > >I believe this is the desired scheme. It is. Registers are temporary copies of pointers, integers, or floats. If you do this: fetchlex P0, "$bar" add P0, P0, 5 then $bar should *immediately* be 5 greater than whatever it was. The only time you should need to explicitly call storelex is when you're putting a new PMC into a named slot. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl 5 to Parrot
Dan Sugalski <[EMAIL PROTECTED]> writes: > At 11:12 AM +0100 1/2/70, James A Duncan wrote: >>Morning (BST) all, >> >> I've started work on B::Parrot, which is a Perl 5 to Parrot >> translation engine. Its very basic at the moment, but I've got it >> successfully translating things like: >> >>my $perliv = 10; >>my $perlpv = "\n"; >>print $perliv; >>print $perlpv; >> >> into working, assemble-able parrot code. Before I go any further on >> this crack-fuelled project is there anything I should be aware of? >> Are others working on this? Have I done far too much crack smoking >> to consider doing something like this now? > > I think what you're doing makes perfect sense, and it's a good way to > go. It should allow for all programs that are essentially static by > CHECK time to be run on Parrot. (Yes, this leaves out runtime > requires, do file, and string evals, but that's a reasonably small > fraction of the programs out there. Runtime requires are okay so long as the file being required is already loaded. And it should be possible to treewalk the resulting optree looking for 'dangerous' constructs so at least there'll be some warning that the thing won't work. A couple of issues though. How much of the standard library does dynamic loading 'cos that's not going to work without some careful thought. Also, XS based modules are going to break unless someone does something very clever indeed. But it's still a fine piece of work. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: Perl 5 to Parrot
Dan Sugalski: > At 6:07 PM -0500 4/4/02, Melvin Smith wrote: > >I also remember there was work already in progress, Simon Cozens mailed > >out a tokenizer and I recall Damian Conway saying he was going to deliver > >a parser (maybe I'm confused as I often am)? I assume this could be reused, > >else we end up with 2 architectures of compiler for Perl5 and Perl6. > > Damian's not working on the perl 6 parser, and never was. Dunno where > the assumption that he was got started. That's a shame. He said that Parse::Perl was one of his deliverables for this quarter; I think that's where the confusion comes from. Perl6::Tokenise is sufficiently flexible that it can be turned into a Perl 5 tokeniser with minimal changes to the ruleset. Indeed, it should really be changed so that the ruleset is part of the tokeniser object, so you can slot in and out rulesets as necessary. (And it will be necessary. Remember that when you see "package" in Perl 6, you're talking Perl 5 again. Oh, and it'll be necessary for regexps, quoted strings and all other "subtokenisation" tasks.) I'd do that, but once again, ENOTIME. If anyone wants to take the module over, please do. -- Oh my god! They killed Kennedy! -- edfromo
Re: PMCs requiring a 'set' dest register?
> >destination register. Why would we *ever* care what's in the destination > >register, since it never gets it's vtable methods called. > > That's not true. The destination needs its set method called. > Otherwise tying/overloading won't work right. Fair enough. I still have the problem brought up in the email that started this thread, however. I'll reiterate it, and a possibly better solution, in the email below. Let me ask how '$a = $b + $c' is supposed to work. Currently, we have an 'add' vtable method, which has self, value, and dest. $a=dest, $b=self, and $c=value. So right now, we never call set, and we transmogrify the destination register PMC directly. So perhaps we should assume that the dest register is a dummy one. We transmogrify and initialize it however we want, in add. Then we use a seperate opcode to store it into the destination register, with set. This means the above code becomes: fetchlex P0, "$b" fetchlex P1, "$c" new P2, DummyPMC add P2, P0, P1 fetchlex P3, "$a" set P3, P2 Now $b's vtable gets called to add, an $a's vtable gets called to set, supporting tied vars and whatnot. This also means that "$a = $a + $a" never modifies itself in the same op. (which was the problem in the example I gave in the email that started this thread), so that the rhs is valid when performing the computation, and once the result is completed, it's then able to store into the lhs and overwrite $a. This requires we create a constraint that one cannot have any of the source registers equal the destination register. If, however, the the below code... fetchlex P0, "$a" fetchlex P1, "$a" fetchlex P2, "$a" add P2, P0, P1 is supposed to work fine, we have two problems: 1) we transmogrify the destination register before we can set it, which means we have to store the result of the add in a temp variable. Lots of methods violate this. (See original email for more clarification on this.) 2) We can't dispatch based upon destination type *and* first-add-argument type with a single op. We already ruled out multi-dispatch.. ;) Mike Lambert
Re: string api
# Keep in mind there is the primitive STRING type which is the S* registers, # and then there is the PMC (PerlString) which uses vtables. I am refering to the parrots internal strings e.g. S* the vtable I am refering to is the 'encoding' vtable of functions in the string struct (*STRING).encoding (I may be misunderstanding this though, please let me know if this is not 'encodings' purpose.) # If you make calls to subroutines that may trigger a GC_collect() # then the STRING you had might be moved or collected. most of the calls that I had intede to use were already part of the internal string api. although I am not certain I would hope that these wouldnt be collected during computation. I have not looked at any of the GC parts of the source yet, I will soon. I take it that "imortal" is a flag that I can |= out of the flag INTVAL? will I need to do this on my temporary STRINGS? sorry for all the questions :-\ Roman
Re: Unary dot
> But suppose you want all .foo to refer to self and not
> to the current topic.
What about
given (self) { }
Also, what about
use invocant;
resulting in all method bodies in scope getting an implied
surrounding given (self) { }.
And what about 'me' or 'i' instead of 'self'?
And "use me;" instead of "use invocant;"?
--
me
PS. Please don't flame me, my assistant wrote this.
Re: Unary dot
Me <[EMAIL PROTECTED]> writes:
>> But suppose you want all .foo to refer to self and not
>> to the current topic.
>
> What about
>
> given (self) { }
>
> Also, what about
>
> use invocant;
>
> resulting in all method bodies in scope getting an implied
> surrounding given (self) { }.
>
> And what about 'me' or 'i' instead of 'self'?
Keep up at the back.
use invocant 'me';
> PS. Please don't flame me, my assistant wrote this.
Whereth hith lithp?
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Avoiding the deadlands
> So, I think #2 is the way to go. We'll add a new flag, > (BUFFER|PMC)_stay_of_execution_FLAG or something, that gets added to > allocated PMCs and Buffers. It'll be treated the same way as the > constant/immortal flag is treated for DOD purposes, with one > difference--there'll be an op which specifically clears the flags. > Since the flag is *not* valid to be set across ops, we're fine. Sounds good to me. This requires that we manually insert this clear_soe_flag op in code, where we want it. If we don't insert it, we effectively make everything immortal/immune, forever. Finding 'proper' places to insert this could be hard to do for the compiler writer, imo. The larger the amount of code in a loop, the more likely this op is to exist inside the loop? Not sure what other heuristics there would be. > Only those functions that *must* set it will, and they are also > required to make sure the stay_of_execution_count interpreter > variable is set to the proper number (or at least large enough) on > abnormal exit. (That way we can keep the flag clearing op from > actually running if there's no reason) Aren't most functions going to be required to set it, indirectly? new_*_header seems like an ideal place to set the SOE flag, and increment the internal counter. But that's going to impact a ton of code. Am I correct in assuming these three functions are what you meant by 'must set it', or were you referring to something else? Mike Lambert
Re: COW for strings
I don't think we are in a position yet to prove much of anything as regards real-world Perl programs, but just one data point as an example - using examples/assembly/life.pasm (changed to 5000 generations) [Pentium 166MHz; linux 2.2.18] Clean CVS checkout (time averaged over 3 runs) 5000 generations in 91.883605 seconds. 54.416672 generations/sec A total of 32768 bytes were allocated A total of 130932 DOD runs were made A total of 10930 collection runs were made Copying a total of 0 bytes There are 81 active Buffer structs There are 256 total Buffer structs Full string COW (time averaged over 3 runs) - 5000 generations in 82.940713 seconds. 60.284025 generations/sec A total of 32768 bytes were allocated A total of 130932 DOD runs were made A total of 2412 collection runs were made Copying a total of 0 bytes There are 81 active Buffer structs There are 256 total Buffer structs -- Peter Gibbs EmKel Systems
Re: Bracekets
On Mon, 2002-04-08 at 20:39, Larry Wall wrote:
> Aaron Sherman writes:
> : If {} goes away in Perl6, then everything you've heard about Perl6 being
> : "not really all that different from Perl5" is either a lie or a damned
> : lie. People keep saying "it's just Perl5, but instead of syntax X, you
> : now use syntax Y". Well, as both X and Y lists grow longer
>
> Your turn to panic, eh? :-)
I'm not really panicking so much as fretting. I love where Perl6 is
going. Among my favorite new features are named parameters,
typing/propertizing, streamlined OO. I love these features, and wouldn't
want them to go away.
It's just that the more I look at Perl6, the more I think of my days
running training classes. I think about all of the times (even in 1998!)
when people would be confused by something because it didn't work the
same as it did in Perl4.
Perl's history is one of subtly dragging script-hackers from thinking
about code a line at a time to thinking about programming in the large.
Perl 6 continues that trend, but accelerates it exponentally, and I'm
just not sure how ready the audience is.
By the same token, please remember those of us who write "Perl programs"
like this:
perl -MNet::Ping -nle 'print "Ghost DHCP lease: $1"
if /lease\s+(\d\S+)/ &&
! Net::Ping->new("icmp")->ping($1)' \
/var/state/dhcp/dhcpd.leases
and
nice du -a | sort -n | tail -300 | tac | perl -nle '
die "Require non-zero disk size!\n" unless $ENV{DF};
if ($. == 1) {
$total = $_ + 0;
next;
}
($size,$rest) = split /\s+/, $_, 2;
if ($rest =~ /^\.\/([\w.\-]+)\//) {
next if $count{$1}++ >= 3;
}
printf "%5.1f%% %5.1f%% %11s %s\n", $size/$ENV{DF}*100,
$size/$total*100, $size, $rest;' |\
head -100
This is about 60-80% of what *I* do with Perl on a daily basis. Only
rarely do I get to craft modules and write XS interfaces to internal
libraries.
If the new, spiffy features of Perl6 are out of my reach that 60-80% of
the time, and I have to use "perl5compat -nle ...", then the usefulness
of this new language will be largely lost on me.
Oh god... I didn't just show off some of my worst hacks on a public
list, did I? Yikes! ;-)
Re: Bracekets
> If the new, spiffy features of Perl6 are out of my reach that 60-80% of > the time, and I have to use "perl5compat -nle ...", then the usefulness > of this new language will be largely lost on me. I'm not sure I follow. What hypothetical features are you talking about here? From what I've seen, Perl 6 is going to be as much of a one-line scripting language as Perl 5, if not more, but also a much better structured language. I mean, look at hyper-operators. If those aren't a one-liner thing I don't know what is. That's also why I was asking for chaining statement modifiers. I don't want to have to put curlies in my one-liner just because it has an if _and_ a while. I mean, if if is just a backwards and, and you can chain ands, why can't you chain ifs? Oh, sorry for the rant. One thing I'd like to see is the argument lost on the -i argument, so I can do search and replaces on files with: perl -pie 's/apple/blueberry/g' :) Luke
string_nprintf format desires
EHLO again folks:
Hope all is well with you all. I believe I will take the old parrot out
of the cage today, so I need to see what you guys were wanting along the
lines of the format string processing. I was thinking of a similar
version to perl5's 'dummed down' format strings. what all must be
provided for? Do I need to fully implement C's *printf() conventions?
I can see routines that will allow me to stringify INTVAL's,
NUMBER's etc, but I haven't even thought about providing for conventions
for pmc's as of yet. How is this handled as each type of PMC would need
methods for this I would assume. Do these functions exist yet?
Am I on taget with this assumption that we are
building a STRING with internal parrot datatypes or should I just be
providing for the c datatypes {or both :-\ }???
Let me just say one last time that I am new to anything of this size or
complexity :) So if my questions seem kinda stupid just let me know off
the list and Ill tone down the traffic :)
Roman
Re: Brackets
if ($a = "\04") {
my only question with doing away with '{' and '}' are dealing with
issues of automagical stringification/number conversion with different
types of the same name. would this be an issue?
would $a be the 5th element of
$ambig[$a] or would it be the "\04" key to $ambig[$a]
PS I dont know if perl 5 allows for octal indexes as it is : )
Roman
Re: Bracekets
Aaron Sherman:
> perl -MNet::Ping -nle 'print "Ghost DHCP lease: $1"
> if /lease\s+(\d\S+)/ &&
> ! Net::Ping->new("icmp")->ping($1)' \
> /var/state/dhcp/dhcpd.leases
This becomes
perl -MNet::Ping -nle 'print "Ghost DHCP lease: $1"
if /lease\s+(\d\S+)/ &&
! Net::Ping.new("icmp").ping($1)' \
/var/state/dhcp/dhcpd.leases
Look, it's even shorter! :)
> nice du -a | sort -n | tail -300 | tac | perl -nle '
> die "Require non-zero disk size!\n" unless $ENV{DF};
> if ($. == 1) {
> $total = $_ + 0;
> next;
> }
> ($size,$rest) = split /\s+/, $_, 2;
> if ($rest =~ /^\.\/([\w.\-]+)\//) {
> next if $count{$1}++ >= 3;
> }
> printf "%5.1f%% %5.1f%% %11s %s\n", $size/$ENV{DF}*100,
> $size/$total*100, $size, $rest;' |\
> head -100
This doesn't change at all.
--
Ever wake up feeling like a null pointer? -Allan Pratt
Re: Bracekets
Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
> On Tue, Apr 09, 2002 at 04:17:38PM +0100, Simon Cozens wrote:
>> Aaron Sherman:
>> >nice du -a | sort -n | tail -300 | tac | perl -nle '
>> >die "Require non-zero disk size!\n" unless $ENV{DF};
>> >if ($. == 1) {
>> >$total = $_ + 0;
>> >next;
>> >}
>> >($size,$rest) = split /\s+/, $_, 2;
>> >if ($rest =~ /^\.\/([\w.\-]+)\//) {
>> >next if $count{$1}++ >= 3;
>> >}
>> >printf "%5.1f%% %5.1f%% %11s %s\n", $size/$ENV{DF}*100,
>> >$size/$total*100, $size, $rest;' |\
>> >head -100
>>
>> This doesn't change at all.
>
> Well, it does but only slightly. $ENV{DF} becomes %ENV{DF} and
> $count{$1} becomes %count{$1} and I'm not sure, but I think that $. is
> changing it's name to something else. Everything else looks like it
> stays the same though.
I think $count{$1} will still work. $count will just be autovivified
as a hashref.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Bracekets
Simon Cozens <[EMAIL PROTECTED]> writes:
> Piers Cawley:
>> Well, no. Because Perl 6 is specified as behaving like perl 5 until
>> told different. Which means that the first translation you give would
>> be a syntax error.
>
> Ouch. Guess I need to go reread A1. Anyway, that makes it easier -
> then there needs to be no translation.
>
> Eh, doesn't that mean Damian's TPJ article is misleading?
Well, there's still going to be a desire to 'upgrade' to perl6
capabilities for scripts that need to be maintained. You do that by
sticking a C at the top and by fixing the syntax
errors. Which should be easy.
Then you get to refactor to more Perl6ish idioms if you want to.
>> If the second one were to become perl6ish, then you'd have to replace
>> $ENV{...} with %ENV{...} and $. might become $*STDIN.recordnum or
>> something.
>
> Oops.
Ah well. All the sorts of things that a convertor will likely be able
to catch.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Unary dot
Me writes:
: > But suppose you want all .foo to refer to self and not
: > to the current topic.
:
: What about
:
: given (self) { }
That wouldn't have the same effect as what we're talking about--it'd be
overruled by any C within. We're talking about how to make .foo
mean self.foo regardless of the current topic.
: Also, what about
:
: use invocant;
:
: resulting in all method bodies in scope getting an implied
: surrounding given (self) { }.
Er, methods already assume that.
: And what about 'me' or 'i' instead of 'self'?
I think "me" is too close to "my".
: And "use me;" instead of "use invocant;"?
And here "me" is referring to something that doesn't even necessarily
exist at the time of the declaration. Who is "me" at this point?
In any event, I'm inclined to think that this whole "selfish" notion of
the object is a bit of a misnomer. We are a programmer. We are not an
object. We use "my" on lexical declarations because it's my piece of
code. Some of that code just happens to deal with objects, but objects
are "them" more than they're "us". C++ probably has the more accurate
idea here with "this", but maybe we've finally found a good place for
the occasionally proposed "it":
it.foo(1);
or even better:
close it;
On the other hand, "it" doesn't interpolate too well. And $_ is still
pronounced "it"...
But think of the commercial possibilities if your program starts out:
just use it;
Though I do wonder what
use it or lose it;
would mean...
Larry
paranoid about GC
Ok now Im paranoid . . . . . If I set BUFFER_immobile_FLAG during a string_make to allocate a temporary string that must be manipulated through the body of a function will the GC leave it alone? if not what must I do? where is this immune/immortal/gc_cant_touch_me_yet flag? Roman
Re: paranoid about GC
On Tue, 9 Apr 2002, Roman Hunt wrote: # Ok now Im paranoid . . . . . # will the GC leave it alone? if not what must I do? where is this # immune/immortal/gc_cant_touch_me_yet flag? disregard my last message I now realize that gc wont stop at my STRING's as I must maintain temporary INTVAL's and UINTVAL's also. since I donot _fully_ understand the GC problem yet I will assume (read: "hope") that the: save = GC_SCRATCHPAD(); GC_SCRATCH_RESTORE(save); type of macros will be written later and I will code the function in hopes of being able to drop them in later. If this is not a good thing to do please let me know. Roman
Re: Unary dot
Larry Wall <[EMAIL PROTECTED]> writes:
> Me writes:
> : > But suppose you want all .foo to refer to self and not
> : > to the current topic.
> :
> : What about
> :
> : given (self) { }
>
> That wouldn't have the same effect as what we're talking about--it'd be
> overruled by any C within. We're talking about how to make .foo
> mean self.foo regardless of the current topic.
Are we? I was looking for a way to unambgiously access the current
object in such a way that topicalizers would still work, eg:
use invocant 'it';
method foo($bar) {
given .wibble($bar) {
when .method { it.do_it(.attrib) }
}
}
(I'm assuming here that, in a method, $bar is *not* the same as @_[0],
which one would declare using C). In the
above chunk of code it'd be really nice if .method and .attrib were
called on the results of .wibble($bar) (which was called on the
current object), whilst 'it' unambiguously refers to the current
object.
The C syntax is just a suggestion (and a way of
dodging arguments about whether to call the object
self/this/that/it/whatever because the programmer can cleave to his
own taste.
> : And "use me;" instead of "use invocant;"?
>
> And here "me" is referring to something that doesn't even necessarily
> exist at the time of the declaration. Who is "me" at this point?
Can I propose an 'abuse' builtin? Then one could say: C, which has to be good for poetry if nothing else.
> In any event, I'm inclined to think that this whole "selfish" notion
> of the object is a bit of a misnomer. We are a programmer. We are
> not an object. We use "my" on lexical declarations because it's my
> piece of code. Some of that code just happens to deal with objects,
> but objects are "them" more than they're "us". C++ probably has the
> more accurate idea here with "this", but maybe we've finally found a
> good place for the occasionally proposed "it":
>
> it.foo(1);
>
> or even better:
>
> close it;
>
> On the other hand, "it" doesn't interpolate too well. And $_ is
> still pronounced "it"...
Personally, I like the 'self' notation; it encourages the programmer
to think the 'right way around'. 'it' encourages one to think of
objects doing things to objects, 'self' encourages to think of objects
taking responsibility for their own data and asking other objects to
do things for it. Hrm... I think I might need to think about that some
more.
>
> But think of the commercial possibilities if your program starts out:
>
> just use it;
>
> Though I do wonder what
>
> use it or lose it;
>
> would mean...
You are a *bad* man Mister Wall.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: macros (was Re: string api)
Melvin Smith wrote: > At 10:30 PM 4/8/2002 -0700, Robert Spier wrote: >>> Keep track of global (or interpreter local) scope with a macro >>> upon entry. >> I shudder every time someone says "macro" on p6i. >> perl5 has several thousand macros defined. (grep for ^#define) (over > Are you counting literals and things like bit values in your grep? Yes, although the later numbers did filter several thousand out. >> This makes it wonderfully challenging to debug. > That might be a bit unfair, I'd argue that it makes it _easier_ > to debug in many cases, particularly with constants. I'll agree with the statement about constants. > 'macro' here is a choice of words... call it an inline function if you > want. Well, calling them inline functions is problematic too. If you have a line of code that looks like: SvPVX( HvKEY( SvPV( foo ) ) ); # made up, but it *could* be from the perl5 source where one of those "inline functions" actually refers to three others, and one is four lines long.. and suddenly you end up tracing through data structure dereferences six layers deep... it's less than amusing. (But can be quite fun.) > I'd be more worried about debugging that computed goto core than a > macro. :) *shudder* -R
Re: Bracekets
Simon Cozens wrote: > > Piers Cawley: > > Well, no. Because Perl 6 is specified as behaving like perl 5 until > > told different. Which means that the first translation you give would > > be a syntax error. > > Ouch. Guess I need to go reread A1. Anyway, that makes it easier - > then there needs to be no translation. My understanding was that perl6 would default to Perl 6 (*not* Perl 5), unless the first thing it encountered was a: package Whatever; statement. > Eh, doesn't that mean Damian's TPJ article is misleading? If it were true, it would have. Yes. ;-) Damian
