On Tue, Mar 18, 2003 at 01:53:59PM +1100, Damian Conway wrote:
Function Assign unless...
true||=
defined //=
exists h
One is almost tempted by something like C??=. Well, almost.
Nonono.. ??= is already for conditionals
Smylers writes:
I don't find the Perl 5 approach ugly: I actually like it, because it does
exactly what it looks like it's doing, and doesn't require learning any
special syntax or keyword.
To have a variable exist beyond outside a sub, you declare it outside that
sub. To prevent that
Merely for the one small thing I might possibly contribute
Would it be useful to have a convenient place to do polls?
I suspect there already is one somewhere, but I'm unaware of it.
I don't want to undermine the authority of the core planning team, but
thought they might like to have a
$a ??= $b :: $c;
Are you serious?
That's completely unnecessary, but so is
$a ||= 1;
I *LIKE* it!!! =o)
__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
Larry Wall writes:
Another question is whether a class containing methods containing
has would be confusing. The $s vs $.s distinction seems to help
a bit there. That would seem to imply that
class foo {
has $s;
has $.t;
}
declares a class attribute vs an
sub foo() {
env $s ??= 0;
$s ++ ;
}
Although I still prefer calling it a trait on the data, I must admit
that I like env...perhaps even better than is retained.
Well, maybe not. But it's a cool thought that it's the environment.
Damian Conway wrote:
[...]
Hence, I would argue, one ought to simply mark it with a trait:
sub foo() {
my $s is retained = 0;
$s++;
}
Other possible trait names:
is kept
is preserved
is permanent
is reused
is saved
is stored
is restored
is
I have commented before on the face that Perl doesn't have Power Tools
(read, idioms) that are well suited for handling XML. Turns out that
Tim Bray agrees.
http://www.tbray.org/ongoing/When/200x/2003/03/16/XML-Prog
-r
--
email: [EMAIL PROTECTED]; phone: +1 650-873-7841
http://www.cfcl.com/rdm
On Tuesday, March 18, 2003, at 06:49 AM, Paul wrote:
Merely for the one small thing I might possibly contribute
Would it be useful to have a convenient place to do polls?
I suspect there already is one somewhere, but I'm unaware of it.
I don't want to undermine the authority of the core
Damian wrote:
Hence, I would argue, one ought to simply mark it with a trait:
FWIW, I personally think this is _absolutely_ the right approach.
Using a trait is a very visible, very obvious way to say what's going
on that is probably easier to remember than adding another keyword to
the
Rich Morin wrote:
I have commented before on the face that Perl doesn't have Power Tools
(read, idioms) that are well suited for handling XML. Turns out that
Tim Bray agrees.
http://www.tbray.org/ongoing/When/200x/2003/03/16/XML-Prog
You may want to look at the perl-xml thread called Tim Bray
[EMAIL PROTECTED] (Rich Morin) writes:
I have commented before on the face that Perl doesn't have Power Tools
(read, idioms) that are well suited for handling XML. Turns out that
Tim Bray agrees.
Tim Bray also says he gives up and uses regexes as a quick and dirty work
around. So maybe these
--- Uri Guttman [EMAIL PROTECTED] wrote:
DC == Damian Conway [EMAIL PROTECTED] writes:
DC Larry wrote:
: sub foo() {
: has $s //= 0; : $s ++ ;
: }
: : print foo, foo, foo;
DC Futhermore, this approach opens another vermiferous can. I
DC would argue that C//= is the
Simon Cozens wrote:
[EMAIL PROTECTED] (Rich Morin) writes:
I have commented before on the face that Perl doesn't have Power Tools
(read, idioms) that are well suited for handling XML. Turns out that
Tim Bray agrees.
Tim Bray also says he gives up and uses regexes as a quick and dirty work
--- Michael Lazzaro [EMAIL PROTECTED] wrote:
Damian wrote:
Hence, I would argue, one ought to simply mark it with a trait:
FWIW, I personally think this is _absolutely_ the right approach.
Hear him! I don't think anyone disagrees that staticness is a trait.
(After all, even the folks that
--- Simon Cozens [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Rich Morin) writes:
I have commented before on the face that Perl doesn't have Power
Tools
(read, idioms) that are well suited for handling XML. Turns out
that
Tim Bray agrees.
Tim Bray also says he gives up and uses
Michael Lazzaro [EMAIL PROTECTED] writes:
As much as people hated it, I think the P6 Operators thread was
*quite* beneficial. It lead to the saving of ^ xor, and the hyper
syntax, and quite a few other improvements, and got things pinned down
squarely. I wouldn't mind seeing more of that
Austin Hastings wrote:
FWIW, I've had to try to rewrite Microsoft's VCPROJ and SLN format
files(*), which look a whole lot like XML. Sadly, if you change the
order of independent entities in the file, Microsoft's internal parser
rejects the file. This despite the fact that MS already has an XML
On Tuesday, March 18, 2003, at 09:55 AM, Austin Hastings wrote:
To me, this says that there's no real commitment to doing XML. What
there is seems to be a recognition that XML format is regular and
comprehensible to others, so writing XML-like files becomes popular.
Yep. Which makes things even
2003-03-18T13:54:12 Michael Lazzaro:
A perl5-native parser can be rigged up fairly easily, but it's
*numbingly* slow compared to the C version. I mean, 20-50 times
slower, by my guess.
That's the nature of the beast; XML requires a lexer which knows
about more than just two or so character
--- Michael Lazzaro [EMAIL PROTECTED] wrote:
On Tuesday, March 18, 2003, at 09:55 AM, Austin Hastings wrote:
To me, this says that there's no real commitment to doing XML.
What
there is seems to be a recognition that XML format is regular and
comprehensible to others, so writing
At 10:54 AM -0800 3/18/03, Michael Lazzaro wrote:
A perl5-native parser can be rigged up fairly easily, but it's
*numbingly* slow compared to the C version. I mean, 20-50 times
slower, by my guess. The speed issue when importing XML-like data
(which we do *very frequently*) is a constant
A quick note before I begin: the stuff in this email isn't just an
implementation detail - it impacts the language too, that's why I'm
posting it here. Should I cross-post to perl6-internals ? (I'm not
really familiar with that list yet)
I've recently spent thought on backtracking into
Damian Conway writes:
on the second thought : its quite strange ( though cute ) that
currently the only way to make lexical persistent variable is based on
garbage collector. it is referenced -- hence it is kept.
may be it have to be more explicit like that
sub counter(){
daemon $s;
Larry Wall writes:
I guess the real question would be, is it an overall simplification to
allow has anywhere? There *is* an object out there representing each
abstract closure (pre-instantiation), but it's a bit of a stretch from
Every block is a closure to Every block is a closure
on the second thought : its quite strange ( though cute ) that
currently the only way to make lexical persistent variable is based on
garbage collector. it is referenced -- hence it is kept.
this brings to the following : every subroutine may have a
daemon object of some sort associated with
Larry Wall writes:
Larry Wall writes:
I guess the real question would be, is it an overall simplification to
allow has anywhere? There *is* an object out there representing each
abstract closure (pre-instantiation), but it's a bit of a stretch from
Every block is a closure to Every
I just read Piers' summary:
Matthijs van Duin wondered if the issue of multiple statement modifiers
has been settled. The thread is long, and the answer is essentially (and
authoritatively) Yes, it's settled. No, you can't do it. So, unless
Larry changes his mind the point is moot.
So apparently I
First of all, Larry, do you have *any* idea how difficult you're making
my life? :^) This stuff is damn hard to implement--I'm at 450 lines
and counting, and I haven't even started the semantic analysis stuff,
let alone *tested* anything. At least I have Filter::Simple's
FILTER_ONLY and P::RD
Austin Hastings wrote:
Request: Change .req method of Routine to .arity
I rather like this idea.
Damian
Brent Dax wrote:
First of all, Larry, do you have *any* idea how difficult you're making
my life? :^) This stuff is damn hard to implement--I'm at 450 lines
and counting, and I haven't even started the semantic analysis stuff,
let alone *tested* anything. At least I have Filter::Simple's
[EMAIL PROTECTED] (Damian Conway) writes:
Just wait till you see P::RD's successor: Perl6::Rules ;-)
I was waiting for its successor, Parse::FastDescent. ;)
Seriously, someone on IRC the other day was claiming that they already
had a P6RE-in-P5 implementation, and did show me some code, but
[EMAIL PROTECTED] (Simon Cozens) writes:
Seriously, someone on IRC the other day was claiming that they already
had a P6RE-in-P5 implementation, and did show me some code, but I've
forgotten where it lives or their real name.
ttp://www.liacs.nl/~mavduin/P6P5_0.00_01.tar.gz
--
IBM:
It
Simon Cozens wrote:
[EMAIL PROTECTED] (Simon Cozens) writes:
Seriously, someone on IRC the other day was claiming that they already
had a P6RE-in-P5 implementation, and did show me some code, but I've
forgotten where it lives or their real name.
ttp://www.liacs.nl/~mavduin/P6P5_0.00_01.tar.gz
[EMAIL PROTECTED] (Damian Conway) writes:
Thanks for the pointer. I'm taking a very different approach, but it
will certainly be useful to have two independent and parallel
implementations to run against each other.
Well, I'll try and dig out the one I wrote at STL too, if regexes haven't
On Wed, Mar 19, 2003 at 10:34:26AM +1100, Damian Conway wrote:
: Brent Dax wrote:
:
: First of all, Larry, do you have *any* idea how difficult you're making
: my life? :^) This stuff is damn hard to implement--I'm at 450 lines
: and counting, and I haven't even started the semantic analysis
On Wed, Mar 19, 2003 at 10:27:24AM +1100, Damian Conway wrote:
: Austin Hastings wrote:
:
: Request: Change .req method of Routine to .arity
:
: I rather like this idea.
I'm not attached to .req. But .arity will be opaque to many
non-mathematicians. Plus, it's throwing out minimum part of
Larry wrote:
: The invocant is bound to both.
Hmmm. I'm not so sure. I can argue it both ways. Sure, it's nice
to be able to attach an absolute rule to method, but I'm inclined
to think that unsigged methods work a little more like Perl 5 in
that case, and just put the invocant (or rather
Larry wrote:
On the other hand, I could see an argument that said anyone who
doesn't know what .arity means shouldn't be writing routines that
depend on it...
That was more or less my line of thought.
Damian
On Wed, Mar 19, 2003 at 01:07:32PM +1100, Damian Conway wrote:
: I specifically avoided type or kind because I didn't want to imply
: mere type matching when something more general might be happening,
: such as smart matching, of which type matching is a small subset.
:
: So maybe $which would be
On Mon, Mar 17, 2003 at 10:03:29PM -0500, Uri Guttman wrote:
: but that is a good name IMO. $s is static vs dynamic (on the stack). the
: other overloaded meanings of static from c/c++ are baggage we can drop.
Gee, if static var makes a subroutine stateful, maybe it's just:
state $s = 0;
Larry wrote:
On Wed, Mar 19, 2003 at 01:07:32PM +1100, Damian Conway wrote:
: I specifically avoided type or kind because I didn't want to imply
: mere type matching when something more general might be happening,
: such as smart matching, of which type matching is a small subset.
:
: So maybe
I think a range object needn't ever expand itself. Consider:
@Floor = (0..Inf,-Inf..-1);
--
Life is like a sewer: what you get out of it
depends on what you put into it. -- Hen3ry
Larry wrote:
Gee, if static var makes a subroutine stateful, maybe it's just:
state $s = 0;
That's very nice, and (unlike Chas) it's verbose enough.
It would also work well for creating class-private shared state.
And for things like loop counters:
while @list {
(state
Damian wrote:
Alternatively, this might be an ideal spot for adverbs:
return :Block @foo;
want :Method Lazy;
caller :{.label eq 'MAINLOOP};
Errr what is that odd and disturbing notation? I don't recall
ever seeing that.
[...]
return Block: @foo;
want
Or maybe Cwhere is just the way we spell the adverb specifier?
And therefore, in turn, perhaps Cwhere is how we set properties on a
subroutine call:
foo('bar') where error('fatal');
Then, within the subroutine call, one can access them via C_.props:
sub foo($arg) {
return 1 if
Luke Palmer wrote:
return :Block @foo;
want :Method Lazy;
caller :{.label eq 'MAINLOOP};
Errr what is that odd and disturbing notation? I don't recall
ever seeing that.
Perhaps not. Larry has long been hoarding the colon. One of the possible uses
for it was as an
To save people from having to re-read the thread, here is the actual
proposal in detail again:
PROPOSAL
Replace the 'if', 'unless', 'when' statement modifiers by identically
named lowest-precedence left-associative operators that short-circuit
from right to left.
This means
On Tue, Mar 18, 2003 at 01:53:59PM +1100, Damian Conway wrote:
: Larry wrote:
:
: : sub foo() {
: : has $s //= 0;
: : $s ++ ;
: : }
: :
: : print foo, foo, foo;
:
: This is interesting, but I think it would be a mistake to give Chas two
: unrelated meanings...
I think it's also a
On Wed, Mar 19, 2003 at 01:07:32PM +1100, Damian Conway wrote:
: Larry wrote:
: A file-scoped $_ could be considered a sort of a half-way house to full
: signatured $_ semantics. You couldn't clobber some other module's $_,
: but you still get a dynamically scoped $_ where naive users expect
LW == Larry Wall [EMAIL PROTECTED] writes:
LW On Mon, Mar 17, 2003 at 10:03:29PM -0500, Uri Guttman wrote:
LW : but that is a good name IMO. $s is static vs dynamic (on the stack). the
LW : other overloaded meanings of static from c/c++ are baggage we can drop.
LW Gee, if static var
Larry Wall wrote:
On Wed, Mar 19, 2003 at 01:07:32PM +1100, Damian Conway wrote:
: Larry wrote:
: A file-scoped $_ could be considered a sort of a half-way house to full
: signatured $_ semantics. You couldn't clobber some other module's $_,
: but you still get a dynamically scoped $_ where
Larry wrote:
I think it's also a mistake to give Cmy two unrelated meanings.
Yes. I fully concede this point. A declarator is the way to go.
They are lexically scoped aliases to properties of the current block.
Err. Properties or traits? Presumably traits, since they're declared at
The Parrot team is proud to announce the release of Parrot version
0.0.10, code named Juice (based on the new -Oj optimization flag).
It is downloadable from
http://www.cpan.org/authors/id/S/SF/SFINK/parrot-0.0.10.tar.gz. If
you would like to check the latest copy out from CVS, see the
The Perl 6 Summary for the week ending 20030316
Spring is in the air, the Apocalypse is here (or imminent, depending on
which sense of the word 'Apocalypse' you are using). We'll start with
perl6-internals as usual, before bracing ourselves for the increased
volume and ploughing on
My main questions are:
Is there a simpler system I'm overlooking?
Which of the two systems would you prefer if speed isn't the issue?
Mechanism 1.
Which system is likely to run faster on parrot?
They're both likely to be very slow.
and maybe also:
What is the current plan?
PC == Piers Cawley [EMAIL PROTECTED] writes:
PC To do that you need to declare the parameter with is
PC copy. Uri noted that he really should keep his finger off the
PC send button until he's read the whole 'megilla', whatever one
PC of those is.
it is appropriate that
--- Uri Guttman [EMAIL PROTECTED] wrote:
PC == Piers Cawley [EMAIL PROTECTED] writes:
PC To do that you need to declare the parameter with is
PC copy. Uri noted that he really should keep his finger off
the
PC send button until he's read the whole 'megilla', whatever
58 matches
Mail list logo
