Re: Proposal: parrot-compilers list
Melvin Smith <[EMAIL PROTECTED]> writes: > In the past couple of years we've seen several sub-projects pop-up > and subsequently fizzle out (maybe due to Parrot slow > progress or maybe due to lack of critical mass). > > I propose creating 'parrot-compilers' as a general > purpose list for any and all language development > (until an appropriate time where said language outgrows the > list maybe...). This might allow many small projects to > feed off the collective energy of other small projects. > > I also volunteer to maintain and mail the FAQ out monthly, > which is something I always liked about comp.compilers. > > The list would center around IMCC and higher up the > compiler stack with the addition of various other topics that might > not be specific to Parrot. Also it would, by namesake, be > language neutral and might bring more people in from > non-Perl camps as well as give some of us compiler > enthusiasts a place to have our long drawn out spam^H^H^H^Hdiscussions > without drowning the mailboxes of the general VM population. As long as it still gets delivered to perl6-all and gets traffic, I'll summarize it happily. I can usually understand the compiler writer's issues with Parrot where the full internals stuff leaves my head spinning so I'd be sorry if you all went off somewhere and I wasn't writing summaries.
[COMMIT] IMCC bug fixes and changes
1) Fixed a couple of bugs in flow analysis code in basic block tracking. 2) IMCC labels can no longer start with #, although they may contain embedded # Reasoning: Its a bit ambiguous to the eye, which isn't too bad, but IMCC should be able to spit out PASM and turn around and compile it from text format (.pasm), which previously it could not, since it handled labels differently than the assembler. IMCC will no longer parse the following as a comment: foo#old comment Instead foo#old is now an identifier (or label if in label context) Add a space: foo #old comment 3) Sub arguments overflow correctly now, I've tested with 30 arguments. -Melvin
Re: [COMMIT] IMCC bug fixes and changes
Melvin Smith <[EMAIL PROTECTED]> wrote: > 2) IMCC labels can no longer start with #, although they may > contain embedded # Suboptimal. Label starting with an underscore are global labels and get an entry in the fixup-table. > Reasoning: Its a bit ambiguous to the eye, which isn't too bad, > but IMCC should be able to spit out PASM and turn around and compile > it from text format (.pasm), which previously it could not, since it > handled labels differently than the assembler. This was suboptimal too, for sure. What I wanted to achieve is, that the generated labels never interfer with user labels. If we want to compile generated PASM, there is no solution for this. We only can reserve some syntax for our own usage. > IMCC will no longer parse the following as a comment: > foo#old comment This seems rather dangerous to me. What about: @reserved_internal_label: @reserved_identifier > -Melvin leo
Re: [perl #24514] [PATCH] examples/pni is out of date
Ilya Martynov <[EMAIL PROTECTED]> wrote: > 1. There are incorrect instructions on running the example > 2. .so extension should be omited in loadlib Thanks, applied. leo
Re: New Example
Jonathan Worthington wrote: Hi, I've attached an example of calling a Win32 API using NCI. Could you please rework it to use the .pcc_begin/.nci_call interface (s. library/libpcre.imc for an example) Jonathan Thanks, leo
Re: IMCC problems with library loading
Jeff Clites <[EMAIL PROTECTED]> wrote: > On Nov 17, 2003, at 11:07 AM, Leopold Toetsch wrote: >> *But*, when writing that stuff, one prelim was, that the compiler sees >> all libs in the same sequence as runtime does. So above code (or your >> second example) is illegal. > Okay for now then. But long-term it seems pretty obvious that this will > be too restrictive. Here are some specific problems: Yep. That's right. > Also, it's still a legitimate question, so for the third time I'll ask > if ".Foo" is valid macro syntax? Its just the constant syntax. A macro can expand to many lines, while a constant is just one substitution. > JEff leo
Re: Control flow variables
Damian Conway <[EMAIL PROTECTED]> writes:
> David Wheeler wrote:
>
>> Isn't that just:
>> for @array_of_random_values_and_types, 'ok' -> $t {
>> when 'ok' { yada(); last }
>> last unless some_sort_of_test($t);
>> }
>> IOW, the topic is only 'ok' when all of the items in the array have
>> been processed
>
> Unless, of course, the string 'ok' is also one of the random_values_and_types.
> Hence my alternative solution.
Or:
my $guard = Object.new;
for @array_of_random_values_and_types, $guard
-> { when $guard { yada(); last }
last unless some_sort_of_test($_) }
If there's some danger of some weird equality thing somehow causing a
problem there, you might need to make a Guard class with a very strict
'=~' implementation, but otherwise I can't see any problem.
Of course, that's better if some_sort_of_test is actually a method,
because then it becomes:
my $guard = class { method some_sort_of_test { yada() }}.new;
for [EMAIL PROTECTED], $guard
-> { last unless .some_sort_of_test }
All of which means you can wrap it up in a macro and prove Simon's
point about what's syntax and what's CP6AN:
macro unless_all( Block &test is parsed //,
Block &consequence, [EMAIL PROTECTED] )
{ my $guard = Object.new;
for [EMAIL PROTECTED], $guard
-> { when $guard { &consequence() ; last }
when &test { last } } }
But I've probably got the signature slightly wrong.
Higher Order Functions/Methods/Macros are great aren't they?
Re: s/// in string context should return the string
Stéphane Payrard <[EMAIL PROTECTED]> writes: > s/// in string context should return the string after substituion. > It seems obvious to me but I mention it because I can't find it > in the apocalypses. Surely it should return the string after substitution, but with an appropriate 'but true' or 'but false' property depending on whether anything was substituted. Though that could have its own problems too.
Re: [perl] RE: s/// in string context should return the string
"Joe Gottman" <[EMAIL PROTECTED]> writes: > - Original Message - > From: "Austin Hastings" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Tuesday, November 18, 2003 3:04 PM > Subject: [perl] RE: s/// in string context should return the string > > >> As a "Bvalue" where possible, so they can cascade and nest. > >Excuse me. I know enough C++ to know the difference between an lvalue > and an rvalue, but what the heck is a BValue? A mystery to me.
RE: Control flow variables
No, because the
if $a
from "return if $a;" doesn't match the production
if [else ]
I so don't want to be anywhere near the Perl6 parser...
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
> -Original Message-
> From: Michael Lazzaro [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 18, 2003 2:06 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Control flow variables
>
>
>
> On Tuesday, November 18, 2003, at 06:38 AM, Simon Cozens wrote:
> > Given that we've introduced the concept of "if" having a
> return status:
> >
> > my $result = if ($a) { $a } else { $b };
> >
>
> Would that then imply that
>
> sub blah {
>... # 1
>return if $a;# 2
>... # 3
> }
>
> ...would return $a if $a was true, and fall through to (3) if it was
> false?
>
>
> > [EMAIL PROTECTED] (Dan Sugalski) writes:
> >>> Luke Palmer:
> That's illegal anyway. Can't chain statement modifiers :-)
> >> Will be able to.
>
> I was under the strong impression that Larry had decided that
> syntactic
> ambiguities prevented this from happening. (Now, of course, you will
> ask me for a cite to the thread, which I can't even begin to find at
> this point...)
>
> MikeL
>
>
Re: Control flow variables
On Tue, Nov 18, 2003 at 11:05:57AM -0800, Michael Lazzaro wrote:
>
> On Tuesday, November 18, 2003, at 06:38 AM, Simon Cozens wrote:
> >Given that we've introduced the concept of "if" having a return status:
> >
> > my $result = if ($a) { $a } else { $b };
> >
>
> Would that then imply that
>
> sub blah {
> ... # 1
> return if $a;# 2
> ... # 3
> }
>
> ...would return $a if $a was true,
That makes no sense. Besides in the above fantasy, the result of the
"if" is the last thing evaluated in the block. In this case, the
block is a single "return" statement. Perhaps it would be clearer
thusly:
my $result = if ($a) { $b } else { $c };# Same as ...
my $result = ($a) ?? $b :: $c; # ?
> and fall through to (3) if it was
> false?
Of course, that's how it works :)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Control flow variables
Michael Lazzaro writes: > [EMAIL PROTECTED] (Dan Sugalski) writes: > > > Luke Palmer: > > > > > That's illegal anyway. Can't chain statement modifiers :-) > > > > Will be able to. > > I was under the strong impression that Larry had decided that > syntactic ambiguities prevented this from happening. I also was under the strong impression that Larry had decreed that we wouldn't have chained statement modifiers ... but I thought it was because Larry had decided they would be a bad thing to have rather than because they aren't feasible. > (Now, of course, you will ask me for a cite to the thread, which I > can't even begin to find at this point...) Me neither. A Google Groups search on perl.perl6.language with the author 'Larry' doesn't through up anything relevant for "statement modifiers" or obvious variants. Smylers
Re: Control flow variables
On Tue, Nov 18, 2003 at 11:37:22PM +0100, Seiler Thomas wrote:
> So... lets call a function instead:
>
> my $is_ok = 1;
> for 0..6 -> $t {
> if abs(@new[$t] - @new[$t+1]) > 3 {
> $is_ok = 0;
> last;
> }
> }
> if $is_ok {
> yada() # has sideeffects...
> }
my $t = 0..6;
yada() if none(abs(@new[$t] ^- @new[$t+1])) > 3;
:-P
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
RE: Control flow variables
Austin Hastings wrote:
> I'm way not sure about how the vector context result of iteration
structures
> will work. Specifically, what happens when a loop forks a thread, or
passes
> to a parallelized coroutine? There may not actually BE a result. (Of
course,
> in a right-thinking system this will be noted, and replaced by a
placeholder
> object that will "wait" for the result if evaluated.)
Whuh? Tangential at best... The result would be the same as in a
non-vectorized version, just repeated automatically for you.
my @b = for @a -> $_ {
...
}
Should be broadly equivalent to:
my @b = map { ... } @a;
- OR -
# (Apologies for the perl5-isms.)
for @a -> $_ {
push @b: do { ... };
}
If the non-vectorized version has hidden a thread join operation in a
tied or otherwise magical result value, then so too would the vectorized
version. But that's a completely orthogonal feature; unrelated and not
in conflict.
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
RE: Control flow variables
> Damian Conway wrote:
>
> > push @moves, [$i, $j];
> > for 0..6 -> $t {
> > if abs(@new[$t] - @new[$t+1]) > 3 {
> > pop @moves;
> > last;
> > }
> > }
Thomas Seiler writes:
> my $is_ok = 1;
> for 0..6 -> $t {
> if abs(@new[$t] - @new[$t+1]) > 3 {
> $is_ok = 0;
> last;
> }
> }
> if $is_ok {
> yada() # has sideeffects...
> }
Ironically, this flow control problem was solved many years ago indeed,
and with considerable elegance. To wit:
my $is_ok = 1;
for 0..6 -> $t {
if abs(@new[$t] - @new[$t+1]) > 3 {
goto SKIP_YADA;
}
}
yada();
SKIP_YADA:
Yeah, so I'm a trouble-maker. Sorry: I don't consider downwards,
scope-escaping goto to be harmful.
Does this cause a bit less heartburn?
YADA: {
my $is_ok = 1;
for 0..6 -> $t {
if abs(@new[$t] - @new[$t+1]) > 3 {
break YADA;
}
}
yada();
}
Loop controls are just goto in disguise, anyhow.
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]>
RE: [perl] RE: s/// in string context should return the string
> -Original Message- > From: Joe Gottman [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 18, 2003 9:58 PM > To: Perl6 > Subject: Re: [perl] RE: s/// in string context should return the string > > > - Original Message - > From: "Austin Hastings" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Tuesday, November 18, 2003 3:04 PM > Subject: [perl] RE: s/// in string context should return the string > > > > As a "Bvalue" where possible, so they can cascade and nest. > >Excuse me. I know enough C++ to know the difference between an lvalue > and an rvalue, but what the heck is a BValue? Something which could be Bound to another rex. Vis (p5): $x =~ s/foo/bar/ =~ s/moo/goo/; Might as well make them chainable. =Austin
RE: Control flow variables
> Austin Hastings wrote:
>
> > I'm way not sure about how the vector context result of iteration
> structures
> > will work. Specifically, what happens when a loop forks a thread, or
> passes
> > to a parallelized coroutine? There may not actually BE a result. (Of
> course,
> > in a right-thinking system this will be noted, and replaced by a
> placeholder
> > object that will "wait" for the result if evaluated.)
>
> Whuh? Tangential at best... The result would be the same as in a
> non-vectorized version, just repeated automatically for you.
Would EVENTUALLY be the same as ...
Sure. The whole iterator/generator thing has already been covered, so I'm
pretty sure we've got the underpinnings.
> my @b = for @a -> $_ {
> ...
> }
>
> Should be broadly equivalent to:
>
> my @b = map { ... } @a;
>
> - OR -
>
> # (Apologies for the perl5-isms.)
> for @a -> $_ {
> push @b: do { ... };
> }
Yes. I think I made that point lower down. In fact, the "collector" behavior
of evaluating for in a vector context should help people transition from
C to C. (Only Satan, or his handpicked successor Damian, will help
them get from there to C/C, however. :-)
> If the non-vectorized version has hidden a thread join operation in a
> tied or otherwise magical result value, then so too would the vectorized
> version. But that's a completely orthogonal feature; unrelated and not
> in conflict.
True, but of course the scalar version doesn't have to wait for the results.
=Austin
RE: thinking about variable context for like()
> -Original Message- > From: Michael G Schwern [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 18, 2003 8:03 PM > To: Potozniak, Andrew > Cc: 'chromatic'; [EMAIL PROTECTED] > Subject: Re: thinking about variable context for like() > > > On Tue, Nov 18, 2003 at 12:23:19PM -0500, Potozniak, Andrew wrote: > > Is anyone going to develop this, or is all of this just > > wishfull/theorhetical thinking? > > Boy, that sounds like a volunteer if I ever heard one! > > Anyhow, it looks like Test::LongString is what you want. Now > say thank you to Rafael. :) Uh.thank you Rafael! Anyway I was just giving my two cents on a possible implementation to see what the "general" perl-qa community thought about it. > > > > If someone will develop this are we going to add it to Test::More > > What's this "we" stuff, bub? :) > > No new functions are going into Test::More. The interface is > pretty much > done. This is ok because... > > > > or create a module wrapped around Test::More with the added > > functionality? > > ...you don't write wrappers around Test::More. You use the > same underlying class Test::More does: Test::Builder. This > includes, oddly enough, like()! > > > -- > Michael G Schwern[EMAIL PROTECTED] > http://www.pobox.com/~schwern/ > Do not try comedy at home! > Milk & Cheese are advanced experts! Attempts at comedy can > be dangerously unfunny! >
Re: Using environment variables to control long running tests (again)
On Wed, Nov 19, 2003 at 01:45:31PM +1100, Andrew Savige wrote: > I think the two environment variables can happily coexist as > shown in the table below: > > PERL_SMOKE PERL_SKIP_LONG_TESTS > Naive User0 0 > Contrary User 1 1 > Impatient User0 1 > Robot 1 0 > > Naive: Gets default behaviour desired by CPAN author > Contrary: Gets opposite of default behaviour desired by CPAN author > Impatient: Never runs long tests > Robot: Always runs long tests Since we've got a very natural 3 valued logic here, you can achieve the same with PERL_SKIP_LONG_TESTS undef = do what the author wants 1 = skip 0 = don't skip Which makes sense - do what the user says if they actually said something otherwise do what the author says, F
Re: Using environment variables to control long running tests (again)
> "Michael" == Michael G Schwern <[EMAIL PROTECTED]> writes: Michael> Disabling tests for subjective reasons (they take "too long", Michael> they don't test critical functionality, etc...) is a slippery Michael> slope. But there are clearly tests that are "tip of the iceberg" as a safety check to ensure that my environment is "close enough" to your devel environment to safely install a tool, versus tests that are "check all functionality" to ensure that during your coding, you don't hose up some existing action. I want to be able to run "tip of the iceberg" tests while installing. And that's all. Michael> For that reason I'd agree with Curtis and say that Michael> everything is always run by default and users can then elect Michael> what to turn off. PERL_SKIP_LONG_TESTS seems like a clear Michael> name. As long as it's consistent, and I can set it easily in CPAN.pm without having to write a wrapper (via make_arg). -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
IMCC Bug? comments after setline
Hi,
IMCC appears to choke on comments after "setline", especially if they
contain digits. Is the lexer expecting /setline +[0-9]+\s*$/ ? Should
this be fixed? It appears to break pirate, which puts comments on every
line.
===
$ cat test.imc
sub __main__
setline 1 # THIS IS JUST A COMMENT 1
end
.end
$ ./parrot test.imc
error:imcc:parse error, unexpected END, expecting '['
in file 'test.imc' line 3
# THIS IS JUST A COMMENT
$ sed -n '134,140p' imcc.l
<*>setline{SP}+ { prev_state = YYSTATE; BEGIN(cmt1); }
{DIGITS} {
valp->t = atoi(yytext);
BEGIN(cmt4);
return LINECOMMENT;
}
{WS}*{EOL} { BEGIN(prev_state) ; line++; }
===
Thanks,
David
--
$_=".--- ..- ... - .- -. --- - . .-. .--. . .-. .-.. .- -.-.".
" -.- . .-.\n";s!([.-]+) ?!$_=$1;y/-./10/;$_=chr(-1+ord pack"B*","01".0 x(5
-length)."1$_");y/DWYKAQMOCVLSFENU\\IGBHPJXZ[~nfb`_ow{}/a-z0-9/;$_!ge;print
Re: configure on windows
Pete Lomax <[EMAIL PROTECTED]> writes: > On 18 Nov 2003 18:37:57 +0100, Juergen Boemmels > <[EMAIL PROTECTED]> wrote: > > >I assume he runs it with perl Configure.pl --ask > Yes > > >The problem is that --ask option of has not the knowledge to change > >the options according to the compiler. I don't know a simple fix for > >this. > > > >A workaround solution to this is: Don't use --ask. Put the Compiler > >directly to the commandline > > > >perl Configure --cc=gcc# for MinGW > >perl Configure --cc=bcc32 # for Borland C++-Builder > > > >Maybe you need to add --jitcapable=0 or --cgoto=0 as well. > > > That certainly moves things in the right direction. > > Determining if your C compiler is actually gcc... > > I had to laugh when that appeared! ;-) > > Some more errors, I still get lots of these three: > gcc.exe: unrecognized option `-nologo' > gcc.exe: unrecognized option `-nodefaultlib' > gcc.exe: unrecognized option `-release' Are there any people out there building parrot on MinGW? config/init/hints/mswin32.pl is far from complete. Could you try out the attached patch. The options are just educated guesses, so you might have to play a little with them. Don't forget to rerun Configure to let your changes take effekt. > test.c:2:21: pthread.h: No such file or directory (ENOENT) > gcc.exe: test.o: No such file or directory (ENOENT) > gcc.exe: no input files > Bad command or file name > > test.c:2:23: arpa/inet.h: No such file or directory (ENOENT) > > test.c:2:21: sysexit.h: No such file or directory (ENOENT) > > test.c:2:24: sys/socket.h: No such file or directory (ENOENT) gcc is searching some system header files which are not found. Aren't these probed config/auto/headers.pl? BTW isn't the file call sysexits.h? > test.o(.text+0x1b):test.c: undefined reference to `_memalign' > collect2: ld returned 1 exit status > test.o(.text+0x23):test.c: undefined reference to `_posix_memalign' > collect2: ld returned 1 exit status > test.c:12: error: parse error before "set_handler" > test.c:12: error: parse error before "__sighandler_t" > test.c: In function `set_handler': > test.c:13: error: `__sighandler_t' undeclared (first use in this > function) > test.c:13: error: (Each undeclared identifier is reported only once > test.c:13: error: for each function it appears in.) > test.c:13: error: parse error before numeric constant > > It does finish, but this is what make does: > D:\Parrot\Parrot>make > echo Compiling with: > Compiling with: > Use of uninitialized value in pattern match (m//) at > tools\dev\cc_flags.pl line > 54, line 15. > Use of uninitialized value in pattern match (m//) at > tools\dev\cc_flags.pl line > 54, line 15. > Use of uninitialized value in pattern match (m//) at > tools\dev\cc_flags.pl line > 54, line 15. > Use of uninitialized value in pattern match (m//) at > tools\dev\cc_flags.pl line > 54, line 15. > Use of uninitialized value in pattern match (m//) at > tools\dev\cc_flags.pl line > 54, line 15. What does the file CFLAGS say? > -nologo -O1 -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -g > -Dan_Sugalski -Larry > -Wall -Ws > D:\Parrot\perl\bin\perl.exe build_tools\ops2pm.pl ops/core.ops > ops/bit.ops ops/c > mp.ops ops/debug.ops ops/dotgnu.ops ops/io.ops ops/math.ops > ops/object.ops ops/p > mc.ops ops/rx.ops ops/set.ops ops/stack.ops ops/string.ops ops/sys.ops > ops/var.o > ps > build_tools\ops2pm.pl: Could not find ops file 'ops/object.op'! > make.exe: *** [lib\Parrot\OpLib\core.pm] Error 2 What make are you using? Could it be that it has problems with long commandlines? bye bö
Re: configure on windows
? $_
? languages/befunge/befunge.pbc
? t/src/headers.t
Index: config/init/hints/mswin32.pl
===
RCS file: /cvs/public/parrot/config/init/hints/mswin32.pl,v
retrieving revision 1.16
diff -u -r1.16 mswin32.pl
--- config/init/hints/mswin32.pl 15 Oct 2003 12:06:24 - 1.16
+++ config/init/hints/mswin32.pl 19 Nov 2003 14:30:26 -
@@ -95,6 +95,19 @@
Configure::Data->set(
link => 'gcc',
libs => $libs,
+ccflags=> '-DWIN32 -DNO_STRICT -DNDEBUG -D_CONSOLE',
+cc_o_out => '-o ',
+cc_exe_out => '-o ',
+cc_debug => '-g',
+
+ld => ${cc},
+ldflags=> '',
+ld_out => '-o ',
+cc_ldflags => '',
+ld_debug => '-g',
+ld_shared => '-mdll',
+libs => '-lmsvcrt'
+
slash => '\\',
ar=> 'ar',
);
Re: [COMMIT] IMCC bug fixes and changes
At 10:52 AM 11/19/2003 +0100, Leopold Toetsch wrote: Melvin Smith <[EMAIL PROTECTED]> wrote: > 2) IMCC labels can no longer start with #, although they may > contain embedded # Suboptimal. Label starting with an underscore are global labels and get an entry in the fixup-table. Then we'll have to come up with another solution. > Reasoning: Its a bit ambiguous to the eye, which isn't too bad, > but IMCC should be able to spit out PASM and turn around and compile > it from text format (.pasm), which previously it could not, since it > handled labels differently than the assembler. This was suboptimal too, for sure. What I wanted to achieve is, that the generated labels never interfer with user labels. If we want to compile generated PASM, there is no solution for this. We only can reserve some syntax for our own usage. I'm not sure which you mean is suboptimal, IMCC spitting out code that can't be compiled, or my fix. > IMCC will no longer parse the following as a comment: > foo#old comment This seems rather dangerous to me. What about: @reserved_internal_label: @reserved_identifier I'd actually considered the same. I think this might work. We definitely have to reserve something that doesn't collide with the assembler, and # won't do. -Melvin
Freeze checkin
Hey folks. Just a quick heads-up--I checked in the preliminary patch for freeze/thaw that Leo sent me for review. It'll change internally a fair amount, and the vtable/low-level API is going to change, but the op-level interface will be stable. I wanted it in before things driged any further, though, so feel free to play but expect it to change rather a lot. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Control flow variables
> "Smylers" == Smylers <[EMAIL PROTECTED]> writes:
Smylers> I also was under the strong impression that Larry had decreed
Smylers> that we wouldn't have chained statement modifiers ... but I
Smylers> thought it was because Larry had decided they would be a bad
Smylers> thing to have rather than because they aren't feasible.
They weren't chained in Perl5, very deliberately.
Larry added modifiers partially to get "do { } while $cond" to work,
and partially because he had used them in RSTS/E BASIC (which I've
also used, and recognized immediately). But when people started
nesting them, the code became incredibly unreadable quickly, so
no-nesting for Perl was a deliberate choice, not an implementation
detail.
Unless Larry has come up with an overwhelming reason to permit them
after years of not having them, I doubt we'd see that (IMHO mistake)
in Perl6.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
RE: Control flow variables
> -Original Message-
> From: Randal L. Schwartz [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 19, 2003 9:46 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Control flow variables
>
>
> > "Smylers" == Smylers <[EMAIL PROTECTED]> writes:
>
> Smylers> I also was under the strong impression that Larry had decreed
> Smylers> that we wouldn't have chained statement modifiers ... but I
> Smylers> thought it was because Larry had decided they would be a bad
> Smylers> thing to have rather than because they aren't feasible.
>
> They weren't chained in Perl5, very deliberately.
>
> Larry added modifiers partially to get "do { } while $cond" to work,
> and partially because he had used them in RSTS/E BASIC (which I've
> also used, and recognized immediately). But when people started
> nesting them, the code became incredibly unreadable quickly, so
> no-nesting for Perl was a deliberate choice, not an implementation
> detail.
This is surprising. Perl has never failed to provide me with an adequacy of
rope in other places. Why get squeamish in this instance?
> Unless Larry has come up with an overwhelming reason to permit them
> after years of not having them, I doubt we'd see that (IMHO mistake)
> in Perl6.
Hmm. While I don't really expect to see leap year code written using nested
modifiers, I think it would be nice to have each of them appear once:
print for @a if $debug;
=Austin
Re: Control flow variables
> "Austin" == Austin Hastings <[EMAIL PROTECTED]> writes: Austin> This is surprising. Perl has never failed to provide me with Austin> an adequacy of rope in other places. Why get squeamish in this Austin> instance? The rope in other places provides overwhelming positive benefits as well, I gather. Everything is a tradeoff. Austin> Hmm. While I don't really expect to see leap year code written Austin> using nested modifiers, I think it would be nice to have each Austin> of them appear once: Austin> print for @a if $debug; I actually consider that an annoying statement. I have to back up three times to figure out what it means. I think Larry was on the right track here. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Control flow variables
> "Randal" == Randal L Schwartz <[EMAIL PROTECTED]> writes: Randal> I actually consider that an annoying statement. I have to back up Randal> three times to figure out what it means. And before someone whips out the Schwartzian Transform to undermine my statement... please note that in Perl6, you'll be able to write that left to right, which I consider a wonderful plus. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Control flow variables
Jonathan Scott Duff writes:
> On Tue, Nov 18, 2003 at 11:37:22PM +0100, Seiler Thomas wrote:
> > So... lets call a function instead:
> >
> > my $is_ok = 1;
> > for 0..6 -> $t {
> > if abs(@new[$t] - @new[$t+1]) > 3 {
> > $is_ok = 0;
> > last;
> > }
> > }
> > if $is_ok {
> > yada() # has sideeffects...
> > }
>
> my $t = 0..6;
> yada() if none(abs(@new[$t] ^- @new[$t+1])) > 3;
>
> :-P
Ghod I love junctions. :-)
Luke
> -Scott
> --
> Jonathan Scott Duff
> [EMAIL PROTECTED]
Re: Control flow variables
Piers Cawley writes:
> All of which means you can wrap it up in a macro and prove Simon's
> point about what's syntax and what's CP6AN:
>
>macro unless_all( Block &test is parsed //,
> Block &consequence, [EMAIL PROTECTED] )
> { my $guard = Object.new;
>for [EMAIL PROTECTED], $guard
> -> { when $guard { &consequence() ; last }
> when &test { last } } }
>
> But I've probably got the signature slightly wrong.
I think the only thing that's wrong with your signature is that you said
"macro" instead of "sub". Well, and &test has to be finessed into an
executable block somehow, but we're not supposed to know how yet.
> Higher Order Functions/Methods/Macros are great aren't they?
What a modern thinker! Use a *function* to do a common task? *What*
are you talking about!? :-)
Luke
Re: [perl] RE: s/// in string context should return the string
On Wed, Nov 19, 2003 at 09:03:38AM -0500, Austin Hastings wrote: : : : > -Original Message- : > From: Joe Gottman [mailto:[EMAIL PROTECTED] : > Sent: Tuesday, November 18, 2003 9:58 PM : > To: Perl6 : > Subject: Re: [perl] RE: s/// in string context should return the string : > : > : > - Original Message - : > From: "Austin Hastings" <[EMAIL PROTECTED]> : > To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> : > Sent: Tuesday, November 18, 2003 3:04 PM : > Subject: [perl] RE: s/// in string context should return the string : > : > : > > As a "Bvalue" where possible, so they can cascade and nest. : > : >Excuse me. I know enough C++ to know the difference between an lvalue : > and an rvalue, but what the heck is a BValue? : : Something which could be Bound to another rex. Vis (p5): : : $x =~ s/foo/bar/ =~ s/moo/goo/; : : Might as well make them chainable. Sigh. There's no =~ operator in Perl 6. And it's not at all clear that ~~ should be associative. In fact, it's not at all clear that ~~, a symmetrical operator, should bind to any kind of mutator (using the term loosely). Operations that have side effects are inherently asymmetrical and should probably be bound with . in any event. And that does associate left to right, though there are no guarantees that the returned value of a method is the left one. The only mutator operator that currently does that is "but". So maybe it could be something like: $x but s/foo/bar/ but s/moo/goo/; We'd have to make "property" context recognize mutators for that to work, though. I'm more inclined to make $x.s/foo/bar/.s/moo/goo/; work somehow. Basically .s would be a postfix quote macro, or some such. I'm not sure I want to propose macromethods just yet. The compile-time vs run-time typing and scoping issues would be hairy. Having said all that about ~~ vs mutators, I note two interesting facts-in-waiting: 1) The ~~ operator likes to match using regexes. 2) We've defined any regex to be a potential mutator if it uses . Ah, consistency... Larry
Re: [perl] RE: s/// in string context should return the string
[EMAIL PROTECTED] (Larry Wall) writes: > Sigh. There's no =~ operator in Perl 6. How should we go about bringing A3 up to match current reality? It is, after all, over two years old now. -- End July 2001 - Alpha release for demonstration at TPC
Re: Control flow variables
On Wed, Nov 19, 2003 at 08:08:49AM +1100, Damian Conway wrote:
: Michael Lazzaro wrote:
:
: >So, just to make sure, these two lines are both valid, but do completely
: >different things:
: >
: >return if $a;
:
: Means:
:
: if ($a) { return }
:
:
: >return if $a { $a }
:
: Means:
:
:if ($a) { return $a } else { return undef }
No, it's a syntax error. You must write
return do { if $a { $a } }
to mean that. At least in my version of Perl 6. AIFIYP.
Sentences are a basic concept in all human languages. I've decided
that it's a bad psychological mistake to overgeneralize phrase-level
syntax to encompass sentence-level syntax. The Perl 6 grammar
will know when it's starting to parse a statement, and will
make distinctions based on that. That implies that any sub/macro
definitions for "if" have to be overloaded on parser state somehow.
We could play "multi" tricks, but I suspect the right solution is
more on the order of how we differentiate prefix:+ from infix:+.
So perhaps statement level "if" is statement:if, while modifier "if"
is modifier:if. Huffman says those should be long anyway.
It may well be that there is a generalization to be made here, but
it's more on the order of foo:bar refers to some grammar rule
or set of rules named foo.
Also, since multi is orthogonal to naming, it'd be possible to define
things such that all variants of "if" and "while" look like this:
multi sub *statement:if (...
multi sub *modifier:if (...
multi sub *statement:while (...
multi sub *modifier:while (...
But that sort of generality would completely screw up the optimizer,
I expect, since multi is an inherently run-time concept. It would
also create a great deal of magical action at a distance. Lexically
scoped macros (or other grammatical mods) are a much better approach
to control structure variation. There might be some room for lexically
scoped multi subs defining control structure, but you'd still probably
take the optimizer hit.
Larry
Re: Control flow variables
On Tue, Nov 18, 2003 at 06:28:59PM -0500, Gordon Henriksen wrote:
: Whuh? Tangential at best... The result would be the same as in a
: non-vectorized version, just repeated automatically for you.
:
: my @b = for @a -> $_ {
: ...
: }
That will be a syntax error. Generators are too mind-stretching to
inflict on novices as ordinary syntax. You'll have to say something
explicit like:
my @b = generate {
for @a -> $_ {
yield ...
}
}
It's vaguely possible that "generate" and "do" are the same thing.
It's quite possible that the best name is something else entirely.
But "for" ain't it...
: Should be broadly equivalent to:
:
: my @b = map { ... } @a;
:
: - OR -
:
: # (Apologies for the perl5-isms.)
: for @a -> $_ {
: push @b: do { ... };
: }
Hmm? I see no perl5-isms there. Or rather, I see no non-perl6-isms...
Larry
Re: Control flow variables
On Wed, Nov 19, 2003 at 09:30:15AM -0700, Luke Palmer wrote:
: Piers Cawley writes:
: > All of which means you can wrap it up in a macro and prove Simon's
: > point about what's syntax and what's CP6AN:
: >
: >macro unless_all( Block &test is parsed //,
: > Block &consequence, [EMAIL PROTECTED] )
: > { my $guard = Object.new;
: >for [EMAIL PROTECTED], $guard
: > -> { when $guard { &consequence() ; last }
: > when &test { last } } }
: >
: > But I've probably got the signature slightly wrong.
So far we've only allowed "is parsed" on the macro itself, not on
individual arguments. Still, that's an interesting idea.
: I think the only thing that's wrong with your signature is that you said
: "macro" instead of "sub". Well, and &test has to be finessed into an
: executable block somehow, but we're not supposed to know how yet.
Hmm, how about statement:unless_all and modifier:unless_all?
: > Higher Order Functions/Methods/Macros are great aren't they?
:
: What a modern thinker! Use a *function* to do a common task? *What*
: are you talking about!? :-)
Well, you mayn't put "is parsed" on a function. Macros have special
rules to enforce lexical scoping of syntax munging, since the syntax
must be known when the call is parsed. A function call can be parsed
without such special knowledge.
Larry
Re: Control flow variables
On Tue, Nov 18, 2003 at 09:36:31PM -0800, Larry Wall wrote:
> As for the original question that started this whole silly thread,
> control structures that return values should probably be considered
> some kind of generator, and have an explicit "yield"-like statement
> that is orthogonal to "last" and such. Such a generator would be
> explicitly marked, as with "do {...}" above, only different. The
> inside of such a generator after the loop is the natural place
> to say what happens if nothing in the loop "works".
I don't understand ... Do you mean something like this?
confer {
for @a -> $x { ... } || beget @results;
}
where "confer" is the do-like marker and "beget" is the yield-like
statement. But why not this?
for @a -> $x { ... } or do { ... }
I need an example.
thanks,
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: [perl] RE: s/// in string context should return the string
On Wed, Nov 19, 2003 at 06:17:33PM +, Simon Cozens wrote: > [EMAIL PROTECTED] (Larry Wall) writes: > > Sigh. There's no =~ operator in Perl 6. > > How should we go about bringing A3 up to match current reality? It is, after > all, over two years old now. Isn't Allison the maintainer? Just prod her with an email or two. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
RE: Control flow variables
Larry Wall wrote:
> On Tue, Nov 18, 2003 at 06:28:59PM -0500, Gordon Henriksen wrote:
>
> > my @b = for @a -> $_ {
> > ...
> > }
>
> That will be a syntax error. Generators are too mind-stretching to
> inflict on novices [...]
I making the point that within the context of this we-wish-loops-were-
expressions discussion, the "for expression" was simply another way
to spell map, at least when autoiterating an array.
I certainly wasn't thinking in terms of coroutines--they absolutely
deserve a large syntactic barrier.
> > # (Apologies for the perl5-isms.)
> > for @a -> $_ {
> > push @b: do { ... };
> > }
>
> Hmm? I see no perl5-isms there. Or rather, I see no
> non-perl6-isms...
It's been a while since I read Apocalypses; I wasn't sure if do { }
(still) meant what I meant it to mean ("the result of the last
statement in the block"). There was also a scalar() in there when I
wrote the apology, but I removed it on further consideration of the
equivalence to map {}. :)
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
Re: Control flow variables
Gordon Henriksen writes:
> Larry Wall wrote:
>
> > On Tue, Nov 18, 2003 at 06:28:59PM -0500, Gordon Henriksen wrote:
> >
> > > my @b = for @a -> $_ {
> > > ...
> > > }
> >
> > That will be a syntax error. Generators are too mind-stretching to
> > inflict on novices [...]
>
> I making the point that within the context of this we-wish-loops-were-
> expressions discussion, the "for expression" was simply another way
> to spell map, at least when autoiterating an array.
>
> I certainly wasn't thinking in terms of coroutines--they absolutely
> deserve a large syntactic barrier.
I don't think generate{} and yield() were supposed to indicate
coroutines. Instead, it's more like Mathematica's Sow[] and Reap[],
which would work (Perl6-ized) as follows:
@a = reap {
sow 1;
some-other-statement;
sow 2;
} # @a is (1,2)
It's a nice concept; it simplifies certain kinds of list processing
greatly. It would easily be implemented with coroutines, which might
also explain the yield().
Luke
Re: Control flow variables
On Wed, Nov 19, 2003 at 09:12:01AM -0600, Jonathan Scott Duff wrote:
: On Tue, Nov 18, 2003 at 09:36:31PM -0800, Larry Wall wrote:
: > As for the original question that started this whole silly thread,
: > control structures that return values should probably be considered
: > some kind of generator, and have an explicit "yield"-like statement
: > that is orthogonal to "last" and such. Such a generator would be
: > explicitly marked, as with "do {...}" above, only different. The
: > inside of such a generator after the loop is the natural place
: > to say what happens if nothing in the loop "works".
:
: I don't understand ... Do you mean something like this?
:
: confer {
: for @a -> $x { ... } || beget @results;
: }
:
: where "confer" is the do-like marker and "beget" is the yield-like
: statement. But why not this?
:
: for @a -> $x { ... } or do { ... }
:
: I need an example.
Sorry, I wasn't being very clear. It wouldn't be logically attached to
the outside of the for, but to the inside of the "confer", or whatever:
@foo = gather {
for @a -> $x { pick $x if mumble($x) }
DEFAULT { @results }
}
In which case you could also write:
@foo = gather {
DEFAULT { @results }
for @a -> $x { pick $x if mumble($x) }
}
But it might be clearer to put it outside:
@foo = gather {
for @a -> $x { pick $x if mumble($x) }
} or @results;
On the other hand, putting the default up front is clearer if the
block is long. Could even be something like:
@foo = gather is default(@results) {
for @a -> $x { pick $x if mumble($x) }
}
Larry
Re: Freeze checkin
On Nov 19, 2003, at 9:04 AM, Dan Sugalski wrote: Just a quick heads-up--I checked in the preliminary patch for freeze/thaw that Leo sent me for review. It'll change internally a fair amount, and the vtable/low-level API is going to change, but the op-level interface will be stable. I wanted it in before things driged any further, though, so feel free to play but expect it to change rather a lot. Two initial concerns: 1) I have a patch which I've been assembling to do ordered destruction. That needs to use the next_for_GC pointer (and I think any alternate implementation would need to as well). But Parrot_freeze_at_destruct() uses next_for_GC. I assume Parrot_freeze_at_destruct is intended to be called from a destroy() method; if so, there's a problem, and we'd need 2 next_for_GC-ish pointers. We certainly can't have a method intended to be called only at destruction-time which is incompatible with proper ordered destruction 2) For the same patch, I'm using something very similar to the vtable->visit method used in the new freeze/thaw code (and actually my method was called vtable->visit as well, which may be where Leo got the name, since I had mentioned this before...). But the ordered-GC code needs to know about "children" in the sense of any referenced PObj (ie, children defined by what needs to be marked in a GC run), whereas the freeze code needs to know about only "logical children" (ie, only those which are intended to be frozen when the "parent" is frozen). So I would modify my ordered GC code to use Leo's vtable->visit, but it has a different notion of what children to visit, so I think we are either going to end up with two very-similar-but-different vtable methods, or we'll need extend vtable->visit to allow it to serve both purposes (either by calling visit with a flag which tells it which type of visitation to do, or by instead having a flag which is passed to the visit_child_function to tell it whether this is a "logical" child or merely a referenced object). Off the top of my head I think that "freeze-children" will always be a subset of "mark-children", so passing a flag to vtable->visit is probably cleaner. JEff
Re: configure on windows
On 19 Nov 2003 16:00:00 +0100, Juergen Boemmels
<[EMAIL PROTECTED]> wrote:
>Are there any people out there building parrot on MinGW?
>config/init/hints/mswin32.pl is far from complete.
I'm quite happy to be the first/only testing this
>
>Could you try out the attached patch.
Sorry, no can do this week. Winders just restored my registry (never
seen that before: a screen quite similar to the all-to-familiar
dos-style scandisk) and it won't boot no more with my latest reg
backup so I have to go with the, I dunno, 3 month old, copy.
So I'm going to delete all the compilers, parrot etc I've installed in
the meantime, and start again from scratch.
Plus I'm away the next four days.
Think I'll try mingw+indigostar this time (I was trying djgpp last go)
unless anyone wants to convince me otherwise.
Tuesday,
Pete
Bearing in mind I can no longer reproduce this:
>What does the file CFLAGS say?
# DO NOT EDIT THIS FILE
# Generated by lib/Parrot/Configure/Step.pm from
config/gen/cflags/root.in
# [ filename | {regex} ] -{removed options} +{added options} s/// ...
#
# Avoid using non-configure controlled +{} directly in this file, as
# it'll most likely break on other platforms.
#
# Note, empty regex/options are just ignored.
#
spf_render.c -{-Wformat-nonliteral} # noisy
tsq.c -{} # never optimize tsq.c!
# imcc file settings
{imcc} -{-Wwrite-strings -Wcast-qual} s/-Wno-unused/-Wunused/
-{-Wformat-nonliteral}
>What make are you using?
>Could it be that it has problems with long commandlines?
as above, I'll reinstall next week & we'll go from there.
Re: Freeze checkin
Jeff Clites <[EMAIL PROTECTED]> wrote: > On Nov 19, 2003, at 9:04 AM, Dan Sugalski wrote: > Two initial concerns: > 1) I have a patch which I've been assembling to do ordered destruction. > That needs to use the next_for_GC pointer (and I think any alternate > implementation would need to as well). But Parrot_freeze_at_destruct() > uses next_for_GC. I assume Parrot_freeze_at_destruct is intended to be > called from a destroy() method; if so, there's a problem, and we'd need > 2 next_for_GC-ish pointers. I don't know yet, when and from where freeze_at_destruct() is run. It seems, that objects are already dead then. That could mean, that destruction ordering is run before. But, even if these 2 get run at the same time, it could be possible to share the next_for_GC pointer - ordering could (if possible) skip some PMCs that don't need ordering. > ... So I > would modify my ordered GC code to use Leo's vtable->visit, but it has > a different notion of what children to visit, ... which, AFAIK isn't carved in stone yet. We don't have a notion for logical children that need ordered destruction. An array holding some scalar PMCs can get destructed in any order. We first should separate destruction (i.e. mainly freeing system memory or maybe closing other resources) and the more HLL-like finalizing, which might depend on other objects to get finalized first. This needs IMHO another vtable, that if present (not default), is a sign for "destruction ordering" or finalizing. > ... so I think we are either > going to end up with two very-similar-but-different vtable methods, or > we'll need extend vtable->visit to allow it to serve both purposes > (either by calling visit with a flag which tells it which type of > visitation to do, The visit vtable passes all "visited" PMCs on to a callback, which puts these on some kind of a TODO list. visit, when called via freeze is different to visit called from thaw. So destruction ordering can setup just its on visit_todo_list() and work on from there. If that's not enough, the visit vtable has all the info, that may be needed in the visit_info structure. > ... or by instead having a flag which is passed to the > visit_child_function to tell it whether this is a "logical" child or > merely a referenced object). I need for freeze/thaw another vist_info structure member called possibly "void *extra" anyway, to be able to e.g. call back to the original PMC to freeze/thaw native data or to handle sparse arrays. While I'd rather have the visit vtable free of such functionality, it seems not achievable. So if destruction ordering has to pass some info, we'll just do it. > JEff I'll try to put together some docs tomorrow, how it currently works and what extensions will be necessary to get freeze/thaw running for all currently known PMCs. We can have a look then, how destruction ordering fits in that scheme. leo
Re: Freeze checkin
On Nov 19, 2003, at 1:34 PM, Leopold Toetsch wrote: Jeff Clites <[EMAIL PROTECTED]> wrote: On Nov 19, 2003, at 9:04 AM, Dan Sugalski wrote: Two initial concerns: 1) I have a patch which I've been assembling to do ordered destruction. That needs to use the next_for_GC pointer (and I think any alternate implementation would need to as well). But Parrot_freeze_at_destruct() uses next_for_GC. I assume Parrot_freeze_at_destruct is intended to be called from a destroy() method; if so, there's a problem, and we'd need 2 next_for_GC-ish pointers. I don't know yet, when and from where freeze_at_destruct() is run. Yeah, that's not clear to me either. (And I think that many other languages/environments have concluded that trying to archive at destruction time turns out not to be a good idea, but that's a separate issue.) It seems, that objects are already dead then. That could mean, that destruction ordering is run before. But, even if these 2 get run at the same time, it could be possible to share the next_for_GC pointer - ordering could (if possible) skip some PMCs that don't need ordering. It's possible that they could be made to work in parallel--that for a particular object we run the freeze right before we run the destroy. I don't think we could archive after destruction (since destruction by design will be tearing down the object and may destroy the state we are trying to archive). ... So I would modify my ordered GC code to use Leo's vtable->visit, but it has a different notion of what children to visit, ... which, AFAIK isn't carved in stone yet. We don't have a notion for logical children that need ordered destruction. An array holding some scalar PMCs can get destructed in any order. I'm not thinking of an array controlling the destruction ordering of its children--I'm talking about the need to destroy() the array itself before destroy()ing its children (that's just what "ordered destruction" means). What I'm really worried about here is the case where something like an array may have a reference to some PMC which its using as a cache, but which is not supposed to be archived along with the array (because it's not part of the "contents" of the array). The GC traversals need to know about this reference, but freezing does not. We first should separate destruction (i.e. mainly freeing system memory or maybe closing other resources) and the more HLL-like finalizing, which might depend on other objects to get finalized first. This needs IMHO another vtable, that if present (not default), is a sign for "destruction ordering" or finalizing. I've been assuming that these two are tied--that for an HLL object, whatever PMC is used to implement it would be responsible for calling the HLL DESTROY() from the PMC's vtable->destroy. If not, then I'm pretty confused--because any recycling of objects is going to need a global view of what is reachable, and of what things reference what other things. But I may be missing something, so I'm anxious to hear your thoughts about this. ... so I think we are either going to end up with two very-similar-but-different vtable methods, or we'll need extend vtable->visit to allow it to serve both purposes (either by calling visit with a flag which tells it which type of visitation to do, The visit vtable passes all "visited" PMCs on to a callback, which puts these on some kind of a TODO list. visit, when called via freeze is different to visit called from thaw. So destruction ordering can setup just its on visit_todo_list() and work on from there. If that's not enough, the visit vtable has all the info, that may be needed in the visit_info structure. So to take my "cache" example from above, destruction ordering would need for the visit_child_function to be called on the cache object, and freeze would need for it to _not_ be. Or, it could always be passed, but then the visit_child_function would need to be able to know "this object is referenced but not logically contained". Either way, it's the vtable->visit which has the information--the question will just be how it "communicates" it to the visit_child_function. ... or by instead having a flag which is passed to the visit_child_function to tell it whether this is a "logical" child or merely a referenced object). I need for freeze/thaw another vist_info structure member called possibly "void *extra" anyway, to be able to e.g. call back to the original PMC to freeze/thaw native data or to handle sparse arrays. While I'd rather have the visit vtable free of such functionality, it seems not achievable. So if destruction ordering has to pass some info, we'll just do it. As I had originally thought of it, the signature was going to be: vtable->visit(visit_child_function, void* extra_info) With this, ordered destruction would pass it's callback-for-referenced-objects as the visit_child_function (and this would internally accumulate objects via the next_for_GC list), and NULL for extra_info. And fo
Re: [perl] RE: s/// in string context should return the string
Simon wrote: > > How should we go about bringing A3 up to match current reality? It is, after > all, over two years old now. We talked about this today. Our current thought is to retroactively write the Synopses and keep those up-to-date (with notes in the outdated parts of the A's and E's pointing to the relevant section of the S's). Allison
RE: Control flow variables
> -Original Message-
> From: Larry Wall [mailto:[EMAIL PROTECTED]
> On the other hand, putting the default up front is clearer if the
> block is long. Could even be something like:
>
> @foo = gather is default(@results) {
> for @a -> $x { pick $x if mumble($x) }
> }
And C is a better name than C, overall.
What does C do?
=Austin
Re: Control flow variables
[EMAIL PROTECTED] (Austin Hastings) writes:
> What does C do?
That's the operator that's used to assign values to C<$^x> and
friends in closures. In all its glory, you give it a set of values,
and it assigns them to a block's undefined variables, quieting those
annoying warnings:
@x = 1..10;
scatter @x {
$the = 1;
$teh + $the * $The
}
# ==> 1 + 1 * 2 = 3
/s
Re: [perl] RE: s/// in string context should return the string
[EMAIL PROTECTED] (Allison Randal) writes: > We talked about this today. Our current thought is to retroactively > write the Synopses and keep those up-to-date (with notes in the outdated > parts of the A's and E's pointing to the relevant section of the > S's). To be honest, I don't care how it's actually done, I just want to avoid having Larry pop up and say "Sheesh, didn't you know X?", where X is something we've never heard of before and contradicts many things he's said publically in the past. -- lathos: nothing can make up for the middle class dinner party couple sex ARSE of Sade
Parsing macros (was: Control flow variables)
Larry Wall wrote:
> So far we've only allowed "is parsed" on the macro itself, not on
> individual arguments. Still, that's an interesting idea.
Forgive me if this has already been addressed, but this could have some
useful applications:
So far, everything I've read about macro parsing concentrates on parsing
the positional arguments; I haven't seen anything about how to go about
defining a custom parse rule for the list arguments. In particular, I'm
thinking about something along the lines of:
macro element(name, [EMAIL PROTECTED] is parsed /\s+/)
is parsed / \< /? () \s* (.*?) /? \> /
{...}
where the "is parsed" trait of the list parameter defines a rule used to
split the string fed into it into a list of arguments.
I could see something similar being done for named parameters, but you'd
need to define both a "split" rule and a name-vs-value parse rule, and
you'd have to address if (and if so, how) a named parameter can be
inserted between positional and/or list parameters.
=
Jonathan "Dataweaver" Lang
__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
Re: Using environment variables to control long running tests (again)
On Wed, Nov 19, 2003 at 07:17:46AM -0800, Randal L. Schwartz wrote: > Michael> For that reason I'd agree with Curtis and say that > Michael> everything is always run by default and users can then elect > Michael> what to turn off. PERL_SKIP_LONG_TESTS seems like a clear > Michael> name. > > As long as it's consistent, and I can set it easily in CPAN.pm without > having to write a wrapper (via make_arg). Consistency? I think you've chosen the wrong programming language, sir! -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ The plot seems complicated at first but with a little study it becomes hopelessly confused. - Peter Schickele, "Hansel and Gretel and Ted and Alice"
