"David L. Nicol" wrote:
>
> Dan Sugalski wrote:
>
> > I do want to have a set of C/XS/whatever sources as part of the test suite
> > as well--right now perl's test suite only tests the language, and I think
> > we should also test the HLL interface we present, as it's just as
> > important in so
Adam Turoff wrote:
>
> A handful of long overdue updates to http://dev.perl.org/rfc have been made:
>
> - All RFCs are now maintained in both POD and HTML.
> HTML conversion is courtesy of pod2html.
>
> - More detailed summaries of all RFCs are available, organized by
> RFC number a
Jerrad Pierce wrote:
>
> That would be my hope too, but as I mentioned, it is seeming somewhat unlikely.
I don't think so. There's lots of proposals out there right now, but
only a very few actually break backwards compatibility. Plus, Larry's
not going to make Perl 6 look like, as Tom would say
=head1 VERSION
Date: 31 Aug 2000
Number: 1
Mailing List: [EMAIL PROTECTED]
Chair: Nathan Wiger <[EMAIL PROTECTED]>
=head1 SUMMARY
The main point which most discussions are currently centering around is
the idea of fundamental embedded objects in Perl 6. With this concept, a
simple s
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
my Dog $spot should call a constructor implicitly
=head1 VERSION
Maintainer: Michael Fowler <[EMAIL PROTECTED]>
Date: 29 August 2000
Last Modified: 31 August 2000
Mailing List: [EMAIL PROTEC
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Perl should support an interactive mode.
=head1 VERSION
Maintainer: Ariel Scolnicov <[EMAIL PROTECTED]>
Date: 31 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 184
Status: Developin
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Thread Programming Model
=head1 VERSION
Maintainer: Steven McDougall <[EMAIL PROTECTED]>
Date: 31 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 185
Status: Developing
=head1 ABSTR
arrays-of-scalars
Reply-To: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Standard support for opening i/o handles on scalars and
arrays-of-scalars
=head1 VERSION
Maintainer: Eryq (Erik Dorfman) <[EMAIL PROTECTED]>
Date: 23 Aug 2
Baris wrote:
> >We're talking about how we'll write Perl 6 programs, not PDL programs. We
> >need to ensure that the syntax we create is Perlish.
> Aggreed.
> But there is nothing wrong with making the syntax user friendly, or am I
> totally missing what perl is?
Perl is user-friendly to Perl use
Jeremy Howard wrote:
> The 1st implementation of Perl 6 may not provide all the optimisations we've
> come to expect from our data crunching language of choice. For this reason
> maybe PDL will continue to exist independently in Perl 6 at least for a
> while, although a fair bit of rewriting will
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> Formats out of core / New format syntax
Good work! This RFC opens the possibility to normalize (e.g. make the
syntax no longer something exceptional) the formats.
>my format $FILE_FORMAT = q(
> @<: @
> $name, $ssn
> );
On 31 Aug 2000, Perl6 RFC Librarian wrote:
>my format $FILE_FORMAT =
> @<: @
> $name, $ssn
> .
>
> Then this is even less different and scary. Get rid of that C and
> it's Perl 5.
s/that C/that C and the dollar sign/;
Cheers,
Philip
--
Philip Newton <[EMAIL PROTECTED]
> =head1 ABSTRACT
>
> There needs to be a way for an object class to define C format
> specifiers for use in formatting objects into strings with C and
> C.
I find myself agreeing with your sentiment, but the approach in this RFC
is not sufficiently general. Why only provide hooks for printf, n
On Wed, 30 Aug 2000 17:55:11 -0700, Nathan Wiger wrote:
>One goal of my RFC was to promote the idea that this
>
> print STDOUT @stuff;
>
>Could be written as:
>
> print STDOUT, @stuff;
>
>Which actually clears something up. You know that STDOUT is now an
>argument, and NOT a function whose re
Baris wrote:
> PDL has PP, which is very nice, but you still need to compile the code (Is
> this correct? Is there any documentation about how to compile pp code?).
There is. It's towards the end of the PP manpage.
> sub sumit{
>my @a = @_;
> $tmp = 0;
>
Baris wrote:
> Looping through the matrix elements is probably most common thing people
do
> in matrix computation. And because of some weird reason I am not aware of,
> the only way to do this efficiently is to write your program in C. So
> everybody I know sooner or later switches to C because o
On Thu, 31 Aug 2000 11:20:25 +1100, Jeremy Howard wrote:
>My hope is that we can have a single set of frozen RFCs in a month's time,
>with incompatible or redundant RFCs withdrawn.
>In the end, I trust Larry to make good in-or-out decisions if we give him
>good input.
Personally, I would like
* Adam Turoff ([EMAIL PROTECTED]) [31 Aug 2000 17:41]:
> A handful of long overdue updates to http://dev.perl.org/rfc have been made:
[...]
> - More detailed summaries of all RFCs are available, organized by
> RFC number and working group. See http://dev.perl.org/rfc/by-number.html
> an
Likely this should be an RFC. I'm too lazy to write it in that format
right now, but I want to send this thing out before it slips my mind
again. Somebody else may pick it up, if he or she wants it. If not, I'll
eventually may have to do it myself.
The articial distinction between
do BLO
Jeremy Howard wrote:
>
> > we are after SIMPLE syntax. This means like C, Fortran, IDL and Matlab.
> > Perl is about working like most people expect.
> >
> Yes, we are after simple syntax. We also want to make to hard things
> possible. Therefore we want a syntax that is also flexible.
>
> > To
At 08:52 AM 8/31/00 -0400, Karl Glazebrook wrote:
>Jeremy Howard wrote:
> >
> > > we are after SIMPLE syntax. This means like C, Fortran, IDL and Matlab.
> > > Perl is about working like most people expect.
> > >
> > Yes, we are after simple syntax. We also want to make to hard things
> > possible
Bart Lateur wrote:
> Personally, I would like to have Larry's fiat *before* trying to iron
> out the incompatibilities. It could be that you throw away something
> that Larry would approve of, and keep something he doesn't like.
I'd vote to go for what we think is the best compromise. If Larry
i
Jeremy Howard wrote:
> @b = (1,2,3);
> @c = (2,4,6);
> @d = (-2,-4,-6);
> $sum = reduce ^_+^_, @b * @c + @d;
>
> should be evaluated as if it read:
>
> $sum = 0;
> $sum += $b[$_] * $c[$_] + $d[_] for (0..$#a-1));
>
> That is, no temporary list is created, and only one loop is requi
Jeremy Howard wrote:
> We're talking about how we'll write Perl 6 programs, not PDL programs. We
> need to ensure that the syntax we create is Perlish. It needs to fit in with
> the rest of the language--our proposals won't get through if programs look
> quite different in sections just because ar
Jeremy Howard wrote:
My plan for this list is to strongly encourage RFC maintainers to work
> together to remove conflicts and incompatibilities from their RFCs. This
> will sometimes require retiring a number of RFCs and writing a new
> consolidated one.
>
> My hope is that we can have a single
Nathan Torkington wrote:
> I'm all for taking proposals on a particular subject (e.g., the PDL
> multidim matrix suggestions, or the lvalue subs suggestions) and
> giving the list a week to boil them down to one RFC that recommends an
> implementation and says what was rejected and why.
ok
> >
At 11:38 AM 8/31/00 +0200, Bart Lateur wrote:
>The articial distinction between
>
> do BLOCK while condition;
>
>and
>
> EXPR while condition;
>
>should go, because the former is nothing but a subcase of the latter.
>Currently, the former executes the do BLOCK at least once, while
Bart Lateur wrote:
>
> Combine this with the RFC that bare filehandles must die, in favor of
> $FH filehandles, and you won't be able to make the distinction between
>
> print $HANDLE, $string;
> and
> print $string, $string;
Sure you will! Please re-read the precedence rules fr
Karl Glazebrook writes:
: I have a lot of respect for Larry, but as a scientist I distrust all this
: deference to one single authority.
Well, sure, but someone still has to decide who gets the grants. :-)
: I don't know if Larry has any experience in scientific programming of the
: sort PDL t
Johan Vromans wrote:
>
> Good work!
Thanks. :-)
> Is there any reason left to maintain formats as something internally
> special?
Well, as you note in your implementation suggestions, it would be nice
if Perl compiled the format the first time around. Along with the
implicit constructors sugge
Hildo Biersma wrote:
>
> > =head1 ABSTRACT
> >
> > There needs to be a way for an object class to define C format
> > specifiers for use in formatting objects into strings with C and
> > C.
>
> I find myself agreeing with your sentiment, but the approach in this RFC
> is not sufficiently general
> I am unemcumbered by any knowledge of the regex engine implementation,
Yeah.
But I do know something about it, and I have already expressed my
informed opinion. Having you come along to say that you don't know
anything about it at all, but that you nevertheless think I am
mistaken, is bizar
Whenever I seem to have this "search backwards" urge (not very often,
I admit), I without much thought just throw memory at it with
reverse($str) =~ /pat/
Or, if that's not the "search backwards" sense intended, then maybe
I'll throw time at it:
$str =~ /.*pat/
Sometimes I've also don
Tom Christiansen writes:
> >However, I really don't want to see 'return' become a kind of 'last'
> >for do{}. How would I return from a subroutine from within a do loop?
>
> You already can't do that (as it were) from within an eval.
Yes, but 'eval' has the semantics "run this code but don'
>AFAICT we could make it a syntax error iff foo is not used in void context;
>Perl must be able to tell whether or not it is used in order to know what
>context the result is in, right?
Well, that depends. Often you must delay till run-time. When Perl
simply sees something like:
sub fn {
>Tom Christiansen writes:
> > >However, I really don't want to see 'return' become a kind of 'last'
> > >for do{}. How would I return from a subroutine from within a do loop?
> >
> > You already can't do that (as it were) from within an eval.
>Yes, but 'eval' has the semantics "run this code bu
[cc'd to internals to check a possible performance problem.]
Steven W McDougall wrote:
> > The more interesting case is this:
> >
> > #!/my/path/to/perl
> > sub foo_generator { my $a = shift; sub { print $a++ } }
> > my $foo = foo_generator(1);
> > $foo->();
> > Thread->new($f
>However, I really don't want to see 'return' become a kind of 'last'
>for do{}. How would I return from a subroutine from within a do loop?
You already can't do that (as it were) from within an eval.
But I while I am not completely bothered by letting the value
dangle here:
($msg, $defs
Tom Christiansen writes:
> >Yes, but 'eval' has the semantics "run this code but don't let it play
> >any funny tricks on me, like dying or anything", where 'do {...} while'
> >has the semantics "a while loop that evaluates its condition at the
> >end". There's no obvious reason why 'return'
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
TC> It just kinda irks me here:
TC> $total += 2 * do {
TC> my $count = 0;
TC> for $n (@nums) { $count += $n }
TC> $count;
TC> };
TC> I rather that were:
TC> $total += 2 * do {
TC> my $count = 0;
Peter Scott writes:
> I dunno, maybe a last in a do block whose value is used by
> something should be a syntax error. We're talking about code like
>
> $x += do { $y = get_num; last if $y == 99; $y } while defined $y;
>
> right? *Shudder*
Yes, but we're also talking about code like
> The more interesting case is this:
>
> #!/my/path/to/perl
> sub foo_generator { my $a = shift; sub { print $a++ } }
> my $foo = foo_generator(1);
> $foo->();
> Thread->new($foo);
> Is $a shared between threads or not?
$a is shared between threads.
The anonymous subroutine
At 02:30 PM 8/31/00 -0500, Christopher J. Madsen wrote:
>Peter Scott writes:
> > I dunno, maybe a last in a do block whose value is used by
> > something should be a syntax error. We're talking about code like
> >
> > $x += do { $y = get_num; last if $y == 99; $y } while defined $y;
> >
Chaim Frenkel wrote:
> You are now biting off quite a bit.
What good is half a transaction? If transactions are to be useful,
they should be fully supported -- including rolling back stuff some
third party module did to its internal variables. (Maybe that's a
little extreme ;)
> I believe that t
Okay, here's a list of functions I think should go into variable vtables.
Functions marked with a * will take an optional type offset so we can
handle asking for various permutations of the basic type.
type
name
get_bool
get_string *
get_int *
get_float *
get_value
At 04:43 PM 8/31/00 -0400, Dan Sugalski wrote:
>Okay, here's a list of functions I think should go into variable vtables.
>Functions marked with a * will take an optional type offset so we can
>handle asking for various permutations of the basic type.
Perhaps I'm missing something... Is this f
Ken Fox wrote:
> Trolling?
No, I'm not, it's the direction that RFC 61 ends up if you let it
take you there.
fast perl6 becomes, as well as slicing, dicing and scratching your
back, a drop-in replacement for gcc.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
I'm confused (I might have missed some discussions, being busy in other
fronts) so please bear with my silly questions.
> type
The basic set-in-stone types are...?
> name
Huh? A name for what? (How does this relate to a 'string'?)
> get_bool
Stored as...? char? int? Boolean or
>> get_int *
>> get_float *
>Could you elaborate on these a lot? What's an 'int'? What's a 'float'?
>Having lately been battling a lot with quad ints and doubles vs long doubles
>I seriously want this interface not to suck.
I was a tad concerned there, too. I'm hoping one can painles
Dan Sugalski wrote:
> get_value
> set_value
Wouldn't these go on the SV and not on the inner type? Maybe I'm
thinking value when you're saying variable? The following seem useful
on variables too:
before_get_value
after_get_value
before_set_value
after_set_value
There ought to b
> Wouldn't these go on the SV and not on the inner type? Maybe I'm
> thinking value when you're saying variable? The following seem useful
> on variables too:
>
> before_get_value
> after_get_value
> before_set_value
> after_set_value
>
> There ought to be specializations of get_value an
[perl6-language removed from the follow-up]
"David L. Nicol" wrote:
> I want to see Perl become a full-blown C/C++ JIT. Since Perl is for
> a large part a compatible subset of C I don't see this as unrealistic.
Trolling? First, Perl is more like lisp with a good syntax -- in other
words about a
Jarkko Hietaniemi writes:
> > I'm not too worried about getting the vtbl right at the first because
> > it will be pretty obvious how it should go once the code starts to form.
>
> Some planning isn't that painful :-)
Yes. Especially given that vtables are an unbenchmarked change. It'd
be good
"David L. Nicol" wrote:
> No, I'm not, it's the direction that RFC 61 ends up if you let it
> take you there.
You seem to be confusing:
(1) linking C code with Perl
with
(2) compiling Perl to C code
There is a world of difference. Swig does (1) pretty well already.
If you want a first c
Fisher Mark wrote:
> The rest of us with our TVs, VCRs, and so on have only compiled
> code in our devices.
I'd buy a microwave that resets to 'JAPH' after a power failure.
Maybe. ;)
- Ken
On Thu 31 Aug, Mark-Jason Dominus wrote:
> Summary report 2831
> RFC 110: counting matches (Richard Proctor)
>
> An extensive side discussion of
>
> $count = () = m/PAT/g;
>
> developed, including an excursion off into context issues. I have
> asked th
On Wed, Aug 30, 2000 at 11:54:29PM -0400, Mark-Jason Dominus wrote:
>
> The big thing I find missing from this RFC is compelling examples.
> You are proposing a major change to the regex engine but you only have
> two examples. Both involve only fixed strings and one of them is
> artificial. I
On Wed, Aug 30, 2000 at 04:07:51PM -0400, mike mulligan wrote:
> Can this be repackaged in such a way that it is a more natural extension of
> the existing regexp language?
>
> The RFC notes that the look-behind construct (?<= pattern) can almost be
> used. Two issues: 1. as currently implement
> "MD" == Mark-Jason Dominus <[EMAIL PROTECTED]> writes:
MD> The $& cost is paid by every regex in the entire program, whether they
MD> used it or not. This is because Perl has no way to tell which regexes
MD> use $& and which do not.
actually it is more like which code refers to $&
> MD> One of Uri's suggestions in RFC 158 was to compute $& only for
> MD> regexes that have a /k modifier. This would solve the $& problem
> MD> because Perl would compute $& only when asked to, and not for
> MD> every other regex in the rest of the program.
>
> the rfc was about makin
>actually it is more like which code refers to $& and which regex that
>caem from. the problem stems from $& being a global and not local like
>$1.
Say what? They scope the same!
sub foo { /./ }
$_ = "stuff";
/.../;
foo();
print $&;
--tom
> in any case, i think we have a fair agreement on rfc 158 and i will
> freeze it if there is no further comments on it.
In light of this:
$& The string matched by the last successful pattern match (not
counting any matches hidden within a BLOCK or eval() enclosed
by the
Tom Christiansen wrote:
> >=item Complex filehandle references
>
> >my %filesystem;
> >my $filename = '/etc/shells';
> >open $filesystem{$filename}, $filename
> >or die "can't open $filename: $!";
> >print <$filesystem{$filename}>;
> >__END__
>
> >GLOB{0xa042284}
>Is some technical reason that this can't be done in perl 5? I hate
>having to add another pair of braces just to reassure perl that I didn't
>forget a comma:
>print {$fh{$name}} "data\n";
Indirect objects are very limited in what they can be.
--tom
Tom Christiansen wrote:
>
> >Is some technical reason that this can't be done in perl 5? I hate
> >having to add another pair of braces just to reassure perl that I didn't
> >forget a comma:
>
> >print {$fh{$name}} "data\n";
>
> Indirect objects are very limited in what they can be.
Curre
Johan Vromans wrote:
>
> You can do that easily:
>
> sub param {
> my ($self, @rest) = @_;
> $self->{aval} = @rest if @rest; # See note
> lreturn $self->{aval};
> }
I've been thinking about this for a couple days. The only problem I see
is that this doesn't allow me to do th
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
"=for testing" - Embedded tests
=head1 VERSION
Maintainer: Michael G Schwern <[EMAIL PROTECTED]>
Date: Aug 31 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 183
Status: Developing
=he
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
JART - Just Another Regression Test
=head1 VERSION
Maintainer: Michael G Schwern <[EMAIL PROTECTED]>
Date: Aug 30 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 182
Status:
On Thu, Aug 31, 2000 at 08:02:36AM -0400, David Corbin wrote:
> > Comments, criticisms, etc. welcome.
> >
>
> Can you put a legend explaining the color code on the pages where the
> colors are used?
Look again.
Next request? ;-)
Z.
On Thu, Aug 31, 2000 at 07:08:38PM +1100, iain truskett wrote:
> * Adam Turoff ([EMAIL PROTECTED]) [31 Aug 2000 17:41]:
> > A handful of long overdue updates to http://dev.perl.org/rfc have been made:
> [...]
> > - More detailed summaries of all RFCs are available, organized by
> > RFC numbe
At 03:45 PM 8/31/00 -0600, Nathan Torkington wrote:
>Jarkko Hietaniemi writes:
> > > I'm not too worried about getting the vtbl right at the first because
> > > it will be pretty obvious how it should go once the code starts to form.
> >
> > Some planning isn't that painful :-)
>
>Yes. Especially
Dan Sugalski wrote:
>
> Okay, here's a list of functions I think should go into variable vtables.
All the math functions are in here. Can the entries that my type does
not use be replaced with other functions that my type does use?
> Functions marked with a * will take an optional type offset
Ken Fox wrote:
> . The real problems of exception handling, closures, dynamic
> scoping, etc. are just not possible to solve using simple C code.
>
> - Ken
I'm not talking about translating perl to C code, I'm talking about
translating perl to machine language.
C is babytalk compared to Perl,
> "DLN" == David L Nicol <[EMAIL PROTECTED]> writes:
DLN> Ken Fox wrote:
>> . The real problems of exception handling, closures, dynamic
>> scoping, etc. are just not possible to solve using simple C code.
>>
>> - Ken
DLN> I'm not talking about translating perl to C code, I'm ta
How about
to_string *
from_string *
as generalizations of formatted/pretty input/output and freeze/thaw
(cf printf/Data::Dumper/Storable)?
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
At 04:59 PM 8/31/00 -0400, Buddha Buck wrote:
>At 04:43 PM 8/31/00 -0400, Dan Sugalski wrote:
>>Okay, here's a list of functions I think should go into variable vtables.
>>Functions marked with a * will take an optional type offset so we can
>>handle asking for various permutations of the basic
> "KF" == Ken Fox <[EMAIL PROTECTED]> writes:
KF> Chaim Frenkel wrote:
>> You are now biting off quite a bit.
KF> What good is half a transaction? If transactions are to be useful,
KF> they should be fully supported -- including rolling back stuff some
KF> third party module did to its inter
At 04:05 PM 8/31/00 -0500, Jarkko Hietaniemi wrote:
>I'm confused (I might have missed some discussions, being busy in other
>fronts) so please bear with my silly questions.
>
> > type
>
>The basic set-in-stone types are...?
int, float, string, ref, hash, array. All of which have multiple lev
At 03:12 PM 8/31/00 -0600, Tom Christiansen wrote:
> >> get_int *
> >> get_float *
>
> >Could you elaborate on these a lot? What's an 'int'? What's a 'float'?
> >Having lately been battling a lot with quad ints and doubles vs long
> doubles
> >I seriously want this interface not to suc
At 05:30 PM 8/31/00 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > get_value
> > set_value
>
>Wouldn't these go on the SV and not on the inner type? Maybe I'm
>thinking value when you're saying variable?
Nope. The get/set value functions are for when something knows what the SV
(or whate
Buddha Buck wrote:
> If I'm stepping on toes here, please tell me...
>
See my other message today for the RFCs I'm thinking of writing. Buddha--you
and I should probably sought out offline which of us will write what RFC.
> RFC 169v2: Matrix Indexing
> Cover my $matrix[$x;$y;$z] syntax
>
Nathan Wiger wrote:
>
> "David L. Nicol" wrote:
> >
> > @a["$i $j $k","$a $y $z"] # two points in DN n-dim syntax
>
> One problem that immediately jumps out at me is how to do this:
>
>@a[[@x], [@y]];
>
> That is, dynamically get your indices. The above seems ok when you know
Christian Soeller wrote:
> No, at least 18. One more piece of semantics that would be appreciated
> is optional omission of trailing dimensions in slices, e.g. for a 3-dim
> @a:
>
> @a[0:1] == @a[0:1;] == @a[0:1;;]
>
I'd rather see the ';' be required, but the '(0..)' not be required, so you
cou
"David L. Nicol" wrote:
>
> > One problem that immediately jumps out at me is how to do this:
> >
> >@a[[@x], [@y]];
>
> I think I dealt with that in the next paragraph, suggesting
>
> @a["@x","@y"]
Well, this is not bad, only it's not without its problems. Say you
wanted to get you
Jeremy Howard wrote:
> I'd rather see the ';' be required, but the '(0..)' not be required, so you
This is not good! There are a lot of routines where it is very useful to
specify a slice as
@a[0]
that should work regardless how many dimensions @a really has. There are
many instances in PDL
> I've been thinking about this for a couple days. The only problem I see
> is that this doesn't allow me to do this:
>
>$oldpath = $tree->path('L','R') = 'R';
>@document = ($title, $junk, $r->xml_extract) = ;
>
> I would still have to use some yeechy combination wit
From: "Peter Heslin" <[EMAIL PROTECTED]>
Sent: Thursday, August 31, 2000 10:51 PM
> I would propose that your version of the syntax might also function in
> the middle of a regexp: /GHI(?`<=DEF)JKL(?`<=^ABC)MNO/ would match the
> start of the alphabet (fixed-length example used for simplicity).
> Steven W McDougall wrote:
> > > The more interesting case is this:
> > >
> > > #!/my/path/to/perl
> > > sub foo_generator { my $a = shift; sub { print $a++ } }
> > > my $foo = foo_generator(1);
> > > $foo->();
> > > Thread->new($foo);
> >
> > > Is $a shared between threads o
>
> use Thread;
>
> $thread = new Thread \&func , @args;
> $thread = new Thread sub { ... }, @args;
>async { ... };
> $result = join $thread;
>
> $thread = this Thread;
> @threads = all Thread;
>
> $thread1 == $thread2 and ...
> yield();
>
> critical { ... };
> $thread = new Thread \&func , @args;
> $thread = new Thread sub { ... }, @args;
>async { ... };
> $result = join $thread;
>
> critical { ... }; # one thread at a time in this block
>
> =item C BLOCK
>
> Executes BLOCK in a separate thread. Syntactically, C BLOCK
> works
Adam Turoff wrote:
>
> Look again.
>
> Next request? ;-)
Can you continue to rock? You're kickin' my ass as RFC Librarian. Nice
job.
-Nate :-)
Larry Wall wrote:
>
> More generally, for all X, I wouldn't mind
> if Perl became the language of choice for X.
Who wouldn't!
But I think that would probably have to be, "if Perl became the language
of choice for X - 1".
Perl's gotta be written in something, after all... ;-)
-Nate
Of course,
> > This is the kind of thing that keeps Perl instructors in business...
>And Perl out of businesses :-(
>More than anything I think the inability to write C DWIMishly
>argues that we need it built-in. But we also need a *very* careful design
>of the semantics.
I'd like to see from this measu
On Thu, 31 Aug 2000 00:22:16 -0400, Buddha Buck wrote:
>A Japanese Perl might want to say
>
> "darn" STDERR print;
>
>for instance (Japanese is a subject-object-verb language).
The Japanese might really like FORTH, then.
Are you proposing that we make JPerl an entirely different language? ;-)
From: Mark-Jason Dominus <[EMAIL PROTECTED]>
Sent: Wednesday, August 30, 2000 11:54 PM
> There are two parts to the $& penalty.
> The first part [ of $& penalty is ] maintaining the information for $&.
> Maintaining this information for your prepos() function is going to
> incur an identical cos
> (mystery: how
> can filling in $& be a lot slower than filling in $1?)
It isn't. It's the same. $1 might even be more expensive than $&.
It appears that many people don't understand the problem with $&. I
will try to explain.
Maintaining the information required by $1 or $& slows down the
perl6-language-regex
Summary report 2831
RFC 72: The regexp engine should go backward as well as
forward. (Peter Heslin)
This topic did not attract much discussion until the very end of the
week. I sent the author a detailed critique, to which he has not
responded.
RFC 93
Jonathan Scott Duff wrote:
>
> How about something like this?
>
> $re = qr/(\d\d)-(\d\d)-(\d\d)/g;
> $re->onmatch_callback(push @list, makedate(^0,^1,^2));
> $string =~ $re;
>
It's not bad, but it loses one thing that I was trying to keep from the
SNOBOL model. If you have (a
This is beginning to sound like something I would support.
Heavens are we approaching some sort of consensus.
This also addresses one pain in current PDL which is the
difficulty of multi-dim indexing.
Buddha Buck wrote:
>
> Here is a quick summary of the proposal:
>
> In the raw, arrays can b
At 12:09 PM 8/31/00 -0400, Karl Glazebrook wrote:
>This is beginning to sound like something I would support.
>
>Heavens are we approaching some sort of consensus.
The one thing the proposal I mentioned doesn't cover is Jeremy's desire to
have $a[$i][$j][$j] be synonymous with $a[[$i,$j,$k]], an
1 - 100 of 178 matches
Mail list logo
