Dan Sugalski wrote:
At 12:14 AM 9/6/00 -0400, Bradley M. Kuhn wrote:
Dan Sugalski wrote:
The decisions should be based on technical merit and general availability.
I would include "available under a free software license" as part of the
definition of "general availability".
You would,
On Wed, 6 Sep 2000 22:58:05 -0400, John Porter wrote:
keys %hash = @things;
is defined as being equivalent to
@hash{ @things } = ();
This is to support hash-based set operations in a more
natural way, i.e.
keys %hash = grep { exists $a{$_} } keys %b;
I have doubts if
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Everything in Perl becomes an object.
=head1 VERSION
Maintainer: Matt Youell [EMAIL PROTECTED]
Date: 25 Aug 2000
Last Updated: 7 Sep 2000
Mailing List: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Lightweight Threads
=head1 VERSION
Maintainer: Steven McDougall [EMAIL PROTECTED]
Date: 30 Aug 2000
Last Modified: 7 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 178
Version: 3
Status:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects: Revamp tie to support extensibility (Massive tie changes)
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 07 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
On 06 Sep 2000 18:04:18 -0700, Randal L. Schwartz wrote:
I think the -1 indexing for "end of array" came from there. Or at
least, it was in Perl long before it was in Python, and it was in Icon
before it was in Perl, so I had always presumed Larry had seen Icon.
Larry?
Do not assume that these
Chaim Frenkel wrote:
UG i don't see how you can do atomic ops easily. assuming interpreter
UG threads as the model, an interpreter could run in the middle of another
UG and corrupt it. most perl ops do too much work for any easy way to make
UG them atomic without explicit locks/mutexes.
Nick Ing-Simmons wrote:
Another good reason for having separate interpreter instances for each
thread is it will allow people to write non-threaded modules that can
still be safely used inside a threaded program. Let's not forget that
the overwhelming bulk of CPAN modules will probably
Adam Turoff wrote:
On Wed, Sep 06, 2000 at 12:14:17AM -0400, Bradley M. Kuhn wrote:
Dan Sugalski wrote:
The decisions should be based on technical merit and general availability.
I would include "available under a free software license" as part of the
definition of "general
2000-09-05-10:53:25 Dan Sugalski:
I don't think it's a good idea to build Perl6 development
infrastructure around non-free software.
I don't think we should make decisions about the software we use
for development based on political views. The decisions should be
based on technical merit
Nick Ing-Simmons wrote:
The tricky bit i.e. the _design_ - is to separate the op-ness from the
var-ness. I assume that there is something akin to hv_fetch_ent() which
takes a flag to say - by the way this is going to be stored ...
I'm not entirely clear on what you mean here - is it
The phrase "die a horrible death" clearly reads that something was
a bletcherous botch--a terribly brain-damaged mistake, if you
would--and so must necessarily be expurgated from the language.
For example, when Larry said, "...this does not mean that some of
us should not want, in a rather
On Wed, 6 Sep 2000 16:24:41 -0500 , Garrett Goebel wrote:
grep { $a $_ and last } @b)
So "last" should return true, or what?
The last operator doesn't return anything does it? It immediately exits the
loop/block in question.
But then, what is the value that would be returned to
Michael G Schwern wrote:
On Sun, Sep 03, 2000 at 09:05:07PM -0700, Russ Allbery wrote:
I also think this may well be a good place to apply one of the ideas of XP
(Extreme Programming, a fairly flexible small-group software design
methodology), namely to write test cases *first* in many
John wrote:
I don't know how grep works internally. I don't know if grep pushes
elements into @a one at a time, or if it returns a finished list of
elements which pass the conditional block. If it is the latter as I
assume, a short-circuited grep would return a list of all
On Fri, 8 Sep 2000 05:59:02 +1100 (EST), Damian Conway wrote:
But it makes "short-circuit as soon as Cgrep
lets through a specific value" ugly:
my $seen;
$has_odd_elem = grep { $seen last; $_%2 ++$seen } @numbers;
Not just ugly. Useless.
--
Bart.
On Thu, Sep 07, 2000 at 10:05:58PM +0200, Bart Lateur wrote:
On Fri, 8 Sep 2000 05:59:02 +1100 (EST), Damian Conway wrote:
But it makes "short-circuit as soon as Cgrep
lets through a specific value" ugly:
my $seen;
$has_odd_elem = grep { $seen last; $_%2 ++$seen }
Garrett wrote:
It almost feels like grep could have been written like this (in
another life): @a = grep (@b) { $_ 2 or last }
http://www.csse.monash.edu.au/~damian/TPC/2000/Romana/perligata.html
;-)
While I'm at it, I'm curious as to why:
$a = 2;
@b = (1, 2, 3,
On Thu, Sep 07, 2000 at 03:42:01PM -0400, Eric Roode wrote:
Richard Proctor wrote:
I think what is needed is something along the line of :
$re = qz{ '(' \$re ')'
| \$re \$re
| [^()]+
};
Where qz is some hypothetical
I think what is needed is something along the line of :
Joe McMahon and I are working on something along these lines.
On Wed 06 Sep, Mark-Jason Dominus wrote:
I've been thinking the same thing. It seems to me that the attempts to
shoehorn parsers into regex syntax have either been unsuccessful
(yielding an underpowered extension) or illegible or both.
SNOBOL:
parenstring = '(' *parenstring ')'
Richard Proctor wrote:
I think what is needed is something along the line of :
$re = qz{ '(' \$re ')'
| \$re \$re
| [^()]+
};
Where qz is some hypothetical new quoting syntax
Well, we currently have qr{}, and ??{} does
On Thu, Sep 07, 2000 at 08:20:42PM +0100, Richard Proctor wrote:
I think what is needed is something along the line of :
$re = qz{ '(' \$re ')'
| \$re \$re
| [^()]+
};
Where qz is some hypothetical new quoting syntax
I found the following reference in the p5p archives to a paper
discussing open source development. I think this should be mandatory
reading for anyone contemplating a contribution to the RFC mountain.
http://www.firstmonday.dk/issues/issue4_10/bezroukov/index.html
Alan Burlison
2000-09-07-17:11:50 Dan Sugalski:
Perl 5's development issues have nothing to do with the code
repository -- [...]
That's certainly possible, but since the reason we're gathered here
together working on trying to launch perl6 is a collective belief
that perl5 has become unmaintainable for
Bennett,
Perforce is a better source code control system than the source
alternatives, and certainly better for the task we face than CVS.
You're certainly not forced to use it. You can, if you rather, grab
snapshot archives, rsync from the repository directory, or even grab a copy
of the
In message [EMAIL PROTECTED]
Chaim Frenkel [EMAIL PROTECTED] wrote:
"TH" == Tom Hughes [EMAIL PROTECTED] writes:
TH Well if we allow value changes in the middle of iterating either
TH keys or values then that is a user visible behaviour change which
TH potentially needs to be
Chaim Frenkel wrote:
I'd like to make the easy things easy. By making _all_ shared variables
require a user level lock makes the code cluttered. In some (I think)
large percentage of cases, a single variable or queue will be use to
communicate between threads. Why not make it easy for the
Chaim Frenkel wrote:
I don't see where you are differing from me.
And different interpreters doesn't completely isolate threads from each
other. You are simply giving each thread its own work/scratch area.
With the internals rewrite it may not need to be a full interpreter.
I think there
Chaim Frenkel wrote:
AB I'm sorry, but you are wrong. You are confusing transactions with
AB threading, and the two are fundamentally different. Transactions are
AB just a way of saying 'I want to see all of these changes, or none of
AB them'. You can do this even in a non-threaded
"TH" == Tom Hughes [EMAIL PROTECTED] writes:
The only real issue is if the change effects the iterator order. Changes
to values should be allowed without out any adverse effects.
TH Well if we allow value changes in the middle of iterating either
TH keys or values then that is a user visible
"AB" == Alan Burlison [EMAIL PROTECTED] writes:
AB Chaim Frenkel wrote:
The problem I have with this plan, is reconciling the fact that a
database update does all of this and more. And how to do it is a known
problem, its been developed over and over again.
AB I'm sorry, but you are wrong.
"AB" == Alan Burlison [EMAIL PROTECTED] writes:
AB The problem with saying that perl should ensure that the operation "$a =
AB $a + $b" is atomic is that it is an unbounded problem. When should $a
AB be automatically locked and unlocked? At the beginning and end of the
AB += op? at the
I would propose that the Cgrep operation should short-circuit if the
block throws an exception, with the value of the expection determining
whether the final invocation of the block should accept the element it
was filtering:
Otherwise nice but until now die() has been a serious thing, now
I would propose that the Cgrep operation should short-circuit if the
block throws an exception, with the value of the expection determining
whether the final invocation of the block should accept the element it
was filtering:
Otherwise nice but until now die() has
Jarkko Hietaniemi wrote:
How about using 'return', then? That could, ahem, return both true and
false values.
Hmm. I think it boils down to the fact that we'd like a grep block
to have characteristics of both a subroutine and a true loop block.
Here's a proposal which would mostly
Damian Conway wrote:
The expression C1 and last does *not* evaluate to true -- it does not
evaluate to *anything*. So the Cgrep is terminated by the Clast
without the block having ever evaluated true. So no element of LIST is
ever "passed through". So the Cscalar grep evaluates to zero.
If one were looking for the first matching item, last would work:
grep { /pat/ and last } @foo
# return()s the value of $_=~/pat/, which will be true
Huh? I can't see how that could work unless you change the existing
semantics of Cand and Clast.
Let's take a step back
On Thu, 07 Sep 2000, Steven W McDougall wrote:
RFC 1 proposes this model, and there was some discussion of it on
perl6-language-flow.
Which is strange, since it was released for this group. Hmmm. But yes,
we did seem to hash out at least some of this before, which, to
Steven's credit, was
-Original Message-
From: Nick Ing-Simmons [EMAIL PROTECTED]
To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Cc: Jarkko Hietaniemi [EMAIL PROTECTED]; Dan Sugalski [EMAIL PROTECTED];
Perl6-Internals [EMAIL PROTECTED]; Nick Ing-Simmons
[EMAIL PROTECTED]
Date: Thursday, September 07, 2000 9:03 AM
Shoot chop. and chomp. Unless you add unchop and unchomp.
Cchomp *has* an inverse.
Surely you know about the unary postfix C.$/ operator?
Of course, you have to be careful. There's a known bug that
the C.$/ doesn't properly "unchomp" if you've ever used the
C$/=`` operator.
;-)
Damian
(or "Allowing built-in functions to use loop blocks")
Reply-To: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Short-circuiting Cgrep, Cmap, and Creduce with Clast
(or "Allowing built-in functions to use loop blocks")
=head1 VERSION
On Fri, Sep 08, 2000 at 02:50:37AM +, Ed Mills wrote:
Shoot chop. and chomp. Unless you add unchop and unchomp. Parity issue. Like
a language with YES and no NO.
Just kill then both.
Although I'm rather fond of symmetry, it's not inherently good.
Rather boring if overused.
I admit to
On Thu, Sep 07, 2000 at 10:48:57PM -0600, Nathan Torkington wrote:
Michael G Schwern writes:
There's one solution, now that we have a nifty source control stuff.
Branch like mad! Feature creep should be discouraged, but if a group
wants to go off and work on something which isn't going to
Michael G Schwern writes:
That sounds bad. I've heard about this style. Code now, refactor
later. Its supposed to avoid the need for sweeping architectural
decisions early in the project, allow you to recover from bad design
decisions and return flexibilty to old code.
Well, yes, but also
On Thu, Sep 07, 2000 at 11:14:34PM -0600, Nathan Torkington wrote:
I view branches in this initial version as highly unlikely to be
useful. We need to have a trunk before we can have branches.
I was actually speaking of both the initial development and on from
there. You don't need a trunk
Michael G Schwern writes:
There's one solution, now that we have a nifty source control stuff.
Branch like mad! Feature creep should be discouraged, but if a group
wants to go off and work on something which isn't going to make it
into the next release they can branch and play.
That
Adam Turoff writes:
3) Those developers prefer Perforce and should not be forced
to use CVS because non-committers prefer it.
Is there anything more to be said about Perforce vs. CVS that *isn't* FUD?
You make it sound like we've decided on Perforce. Dan, how about you
[I'll take off my black hat for a moment...]
Okay, this is the FIRST TIME I've ever seen indirect object syntax
used for anything useful. (That's praise, BTW)
I was going to suggest that KEYS and VALUES methods be added to tied
hashes, but this RFC makes it all moot. Well done.
[Black hat
Steven W McDougall [EMAIL PROTECTED] writes:
DS Some things we can guarantee to be atomic.
This is going to be tricky. A list of atomic guarentees by perl will be
needed.
From RFC 178
...we have to decide which operations are [atomic]. As a starting
point, we can take all the operators
Chaim Frenkel [EMAIL PROTECTED] writes:
"JH" == Jarkko Hietaniemi [EMAIL PROTECTED] writes:
JH Multithreaded programming is hard and for a given program the only
JH person truly knowing how to keep the data consistent and threads not
JH strangling each other is the programmer. Perl shouldn't
Chaim Frenkel [EMAIL PROTECTED] writes:
Some series of points (I can't remember what they are called in C)
Sequence points.
where operations are consider to have completed will have to be
defined, between these points operations will have to be atomic.
No, quite the reverse - absolutely no
Jarkko Hietaniemi wrote:
Multithreaded programming is hard and for a given program the only
person truly knowing how to keep the data consistent and threads not
strangling each other is the programmer. Perl shouldn't try to be too
helpful and get in the way. Just give user the bare
Chaim Frenkel wrote:
The problem I have with this plan, is reconciling the fact that a
database update does all of this and more. And how to do it is a known
problem, its been developed over and over again.
I'm sorry, but you are wrong. You are confusing transactions with
threading, and the
Dlux [EMAIL PROTECTED] writes:
| I've deemed to be "too complex".) (Also note that I'm not a
| database
| guru, so please bear with me, and don't ask me to write the code
| :-)
Implementing threads must be done in a very clever way. It may be
put in a shared library (mutex
From: Damian Conway [mailto:[EMAIL PROTECTED]]
From: Garrett Goebel
@passed = grep { 2 $_ and last } (1, 2, 3, 2, 1);
would leave
@passed = (1, 2)
I believe the above would leave:
@passed = ();
since on the first call to the block 2 1 is true, so the Clast is
Bart Lateur wrote:
Currently, attempting to use objects in a string context
yields garbage:
print "r is $r-func"; # "OBJ=HASH(0xef958)-func"
print "r is ", $r-func; # works, but clumsy
Does this expand to regexes?
/$foo-blah/
To be consequent, it should.
On 14 Aug 2000 23:29:38 -, Perl6 RFC Librarian wrote:
Currently, attempting to use objects in a string context
yields garbage:
print "r is $r-func"; # "OBJ=HASH(0xef958)-func"
print "r is ", $r-func; # works, but clumsy
I've not seen any comments on this RFC yet. But this idea
On Wed, Sep 06, 2000 at 03:37:55PM -0400, David Corbin wrote:
Question: Is there value in extending the regex/pattern engine to
support matching patterns in a list of foobars?
I can see this taking two forms (beyond the strings we have today).
One is matching number patterns (fibonaci,
Can be rewritten as the shorter and more readable:
($name) =~ split /\s+/;
$string =~ quotemeta;
@array =~ reverse;
@vals =~ sort { $a = $b };
$string =~ s/\s+/SPACE/;# looks familiar
$string =~ m/\w+/; # this too
@strs =~ m/\w+/;
2. Many people - including Larry - have voiced their desire
to see =~ die a horrible death
Please provide a look-up-able reference to Larry's saying that he
wanted to =~ to die horrible death. That's very strongly worded
for him. Are you sure this tale hasn't merely grown in the
From: Tom Christiansen [EMAIL PROTECTED]
Sent: Thursday, September 07, 2000 11:20 AM
Which can of course be written in an immeasuably more legible fashion
using current Perl, a little-known language:
($name) = split /\s+/, $name;
$string = quotemeta($string);
@array =
2. Many people - including Larry - have voiced their desire
to see =~ die a horrible death
Please provide a look-up-able reference to Larry's saying that he
wanted to =~ to die horrible death.
Larry said:
# Well, the fact is, I've been thinking about possible ways to get rid
#
Mark-Jason Dominus wrote:
Larry said:
# Well, the fact is, I've been thinking about possible ways to get rid
# of =~ for some time now, so I certainly don't mind brainstorming in
# this direction.
That is in
[EMAIL PROTECTED]
which is archived at
But you said "lists" up there and that sparked an idea in me ... What
does
@a =~ /pattern/;
currently do? AFAICT, nothing useful. But it could be a syntactic
shorcut for a pattern matching grep()
That changes semantics in places you might not expect. What does
fn() =~
(We are not (quite) discussing what to do for Perl6 any longer. I'm
going though a learning phase here. I.e. where are my thoughts
miswired.)
"AB" == Alan Burlison [EMAIL PROTECTED] writes:
Actually, I wasn't. I was considering the locking/deadlock handling part
of database engines. (Map row
"AB" == Alan Burlison [EMAIL PROTECTED] writes:
my $a :shared;
$a += $b;
AB If you read my suggestion carefully, you would see that I explicitly
AB covered this case and said that the internal consistency of $a would
AB always be maintained (it would have to be otherwise the interpreter
AB
At 03:02 PM 9/7/00 +0100, Nick Ing-Simmons wrote:
Alan Burlison [EMAIL PROTECTED] writes:
Jarkko Hietaniemi wrote:
Multithreaded programming is hard and for a given program the only
person truly knowing how to keep the data consistent and threads not
strangling each other is the
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
hash slicing
=head1 VERSION
Maintainer: David Nicol [EMAIL PROTECTED]
Date: 7 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 201
Version: 1
Status: Developing
=head1 ABSTRACT
a more
On Thu, Sep 07, 2000 at 10:22:17PM -0600, Nathan Torkington wrote:
Michael G Schwern writes:
I was expecting those two crufty features to be removed. If they
aren't, a third won't hurt.
Might want to add this assumption to the RFC. Or perhaps another RFC
to junk reset()'s current meaning.
I don't think Cgrep should be able to eat unintentional exceptions.
Perhaps it could short-circuit if the exception is 1 or false, as
opposed to true or false?
No objection here.
Damian
On Wed, Sep 06, 2000 at 06:39:38PM -, Perl6 RFC Librarian wrote:
=head1 TITLE
Retire chop().
Awww, does this mean we won't be seeing chip() and chimp() in Perl 6?
'Pends on whether you modulate them.
--tom
On Thu, Sep 07, 2000 at 06:48:35PM -0600, Tom Christiansen wrote:
Awww, does this mean we won't be seeing chip() and chimp() in Perl 6?
'Pends on whether you modulate them.
KCHP 1570 on your AM dial!
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just
'Pends on whether you modulate them.
KCHP 1570 on your AM dial!
Aw, not *another* one of those easy-listening Californian motor cop stations!
Damian
John Porter wrote:
heh. for a normal sub,
sub foo {
return( 42 );
}
finds OMWTDI as
sub foo {
42;
last;
}
Somehow, this seems like very natural perl to me.
--
John Porter
I'd like to see
Damian Conway wrote:
I would propose that the Cgrep operation should short-circuit if the
block throws an exception, with the value of the expection determining
whether the final invocation of the block should accept the element it
was filtering:
Otherwise nice
Counterproposal: grep, map, etc. define two implicit magic labels
'ACCEPT' and 'REJECT' that behave in the expected way, so you use
($first_small) = grep { ($_ 2) and last ACCEPT } @list.
Reminds me of "next LINE" in perl -p or perl -n.
--tom
Both are pretty much the same. Combining them, I'd say that exceptions
should remain exceptional.
I'd say short-circuiting a vector operation was exceptional enough. :-)
Counterproposal: grep, map, etc. define two implicit magic labels
'ACCEPT' and 'REJECT' that behave in the
Damian Conway wrote:
A Cgrep such as:
@array = grep BLOCK LIST
is equivalent to:
@tmp = ();
foreach (LIST) { push @tmp, $_ if do BLOCK }
@array = @tmp;
That similarity would not change in any way under the proposal
(except to be made stronger!)
Damian Conway wrote:
Both are pretty much the same. Combining them, I'd say that exceptions
should remain exceptional.
I'd say short-circuiting a vector operation was exceptional enough. :-)
I'd say it's exceptional sometimes, and very ordinary other times, and
I'd prefer to be
On Thu, 07 Sep 2000, Michael G Schwern wrote:
Awww, does this mean we won't be seeing chip() and chimp() in Perl 6?
Someone, (and I've lost who, exactly) was interested in taking those
off my hands for a String::Utils module.
I believe it was quite clear, however, that my
On Fri, Sep 08, 2000 at 09:45:54AM +1100, Damian Conway wrote:
I would propose that the Cgrep operation should short-circuit if the
block throws an exception, with the value of the expection determining
whether the final invocation of the block should accept the element it
was filtering:
I
Exactly the sort of chicanery grep/last is meant to avoid. So the question
becomes, how do we crowbar "last" in without altering the returned value in
Cmap blocks. I'm for putting it after a comma. Which matches the syntax of
John Porter's proposal about internally converting the block to a
On Wed, Sep 06, 2000 at 06:39:38PM -, Perl6 RFC Librarian wrote:
=head1 TITLE
Retire chop().
Awww, does this mean we won't be seeing chip() and chimp() in Perl 6?
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant
84 matches
Mail list logo
