Lightning flashed, thunder crashed and Bart Lateur [EMAIL PROTECTED] whis
pered:
| I'm really beginning to like
|
| $string3 = $string1 _ $string2;
|
| The underscore indeed connects the two strings.
This still breaks because _ is a valid word character. Again, we have to
make the
Lightning flashed, thunder crashed and Nathan Wiger [EMAIL PROTECTED] whisper
ed:
| Under this proposal, string concatenation would be acheived by the
| *combination* of and +. So, in Perl 5 you would have something like
| this:
|
|$string3 = $string1 . $string2;
|
| In Perl 6, you would
Lightning flashed, thunder crashed and Casey West [EMAIL PROTECTED] whispere
d:
| I would consider thinking about the bigger problem of:
|
| $string = foo() [something here] bar();
In either case, quoting the operands isn't going to work.
$string = foo() + bar();
And, my one argument still
Lightning flashed, thunder crashed and Nathan Wiger [EMAIL PROTECTED] whisper
ed:
| Michael G Schwern wrote:
|
| Oh, not to seed the clouds or anything, but what about += and .=?
| Any proposal will have to deal with those.
|
| Under what I originally posted:
|
|$a += $b;# string
|
Lightning flashed, thunder crashed and Graham Barr [EMAIL PROTECTED] whispered:
| What's wrong with something like:
|
| $foo = $a :+ $b;
|
| I was thinking along those lines too.
Maybe this is a crazy (or stupid) idea, but why couldn't we use the $, @,
and % characters?
@foo = @a
Lightning flashed, thunder crashed and Larry Wall [EMAIL PROTECTED] whispered:
| I'm thinking concat will be ~. Furthermore, I'm thinking unary ~ will
| be stringify, and unary ^ will be bit complement, on the theory that
| bit complement is like xoring with 0x. And unary + will be a
|
Lightning flashed, thunder crashed and John Porter [EMAIL PROTECTED] whispered
:
| Yep; the perl manpage has said, since time immemorial, that
| the fact that -w was not on by default is a BUG.
I don't know that I would say time immemorial. It wasn't in the man for
4.036. I can only find man
Lightning flashed, thunder crashed and "Branden" [EMAIL PROTECTED] whisp
ered:
| For the list managers: Could we have a list apart from -language, so that we
| don't bother all with this `par'-issue ??? Please? Perhaps a list that
| includes the issue on directory structure, and other issues
Lightning flashed, thunder crashed and [EMAIL PROTECTED] whispered:
| To make a simple loop, Perl offers you: for, foreach, while, until,
| {redo}, map, grep, //g, goto and recursion. Which 9 of them do you
| propose to drop from the language so Perl causes less confusion?
|
| There Is More Than
Lightning flashed, thunder crashed and Jarkko Hietaniemi [EMAIL PROTECTED] whispered
:
| I guess it's part of the can of sub-second worms: if we do sleep(),
| people will ask why don't we do time() and alarm(), too. sleep() and
| alarm() we could get away with more easily, but changing time() to
Lightning flashed, thunder crashed and Nathan Wiger [EMAIL PROTECTED] whisper
ed:
| But the big problem is that there's a lot of stuff that's based off of
| time() right now, like stat(), lstat(), etc, etc. When you think of the
| cascading effects of changing Perl's timekeeping it gets really,
Lightning flashed, thunder crashed and Michael G Schwern [EMAIL PROTECTED] wh
ispered:
| On Thu, Aug 24, 2000 at 08:29:21PM -, Perl6 RFC Librarian wrote:
| The Cdbmopen and Cdbmclose commands are legacy commands which have been
| deprecated for at least 5 years. They should be removed from
Lightning flashed, thunder crashed and "Ed Mills" [EMAIL PROTECTED] whispe
red:
| So we establish a var $something=n where n is the array origin.
You mean something like $[, which we've had for many, many years. And
which for many, many years we've discouraged the use of?
$[ The
Lightning flashed, thunder crashed and [EMAIL PROTECTED] (Johan Vromans) whi
spered:
| Do we have an RFC yet that proposes Perl to be easier parsable?
| Damian?
Great idea. I'd love to see us come up with some "meta" RFCs which say
what the main goals of perl6 are. Then we could align the
Lightning flashed, thunder crashed and "Jeremy Howard" [EMAIL PROTECTED] whispered:
| No. They are lazily evaluated and require special optimisations to allow
I don't completely understand this whole lazy evaluation, so I'm confused
how these functions would work on them. Explain to me how you
Lightning flashed, thunder crashed and "Jeremy Howard" [EMAIL PROTECTED] whispered:
| No, neither proposal makes sense. Arrays can be stored compactly and
|
| $a[1_000_000_000] = 'oh, really?' # :-)
|
| my int @a: sparse;
| $a[1_000_000_000] = 'Yes, really!' # :P
|
| OK, so I cheated...
Lightning flashed, thunder crashed and Jonathan Scott Duff [EMAIL PROTECTED]
whispered:
| Um, it's not guaranteed to blow up in 2038. That's an implementation
| detail. IF we implement our time values as 64-bit integers (for
| instance), we'll long out-live the 2038 deadline.
I don't know
Lightning flashed, thunder crashed and Russ Allbery [EMAIL PROTECTED] whispere
d:
| Arrays are ordered. Hashes are not. Sure, you can iterate over a hash,
| but add an element to one and you can change the order of everything in
| it.
|
| Formally, I believe it's permissable for a hash
Lightning flashed, thunder crashed and Perl6 RFC Librarian [EMAIL PROTECTED]
whispered:
| =head1 TITLE
|
| Builtin: partition
|
| =head1 ABSTRACT
|
| It is proposed that a new function, Cpartition, be added to Perl.
| Cpartition($partition_size, \@list) would return @list broken into
|
Lightning flashed, thunder crashed and Nathan Wiger [EMAIL PROTECTED] whisper
ed:
| I suggest a modification to this RFC: if chomp() is called without args,
| it modifies $_ directly, consistent with its current implementation.
| That way you can write:
If it is called without args, it really is
Lightning flashed, thunder crashed and Perl6 RFC Librarian [EMAIL PROTECTED]
whispered:
| =head1 TITLE
|
| Eliminate the optional Csub for CBEGIN etc block declarations
It seems to me it makes more sense to require the sub, but to move them
into a different namespace (CORE:: or Perl:: or
Lightning flashed, thunder crashed and Perl6 RFC Librarian [EMAIL PROTECTED]
whispered:
| =head1 TITLE
|
| Builtins: zip() and unzip()
|
[snip]
|
| its arguments. Cunzip($list_size, \@list) would reverse this operation.
|
[snip]
|
| If the list to be unzipped is not an exact multiple of the
Lightning flashed, thunder crashed and Dan Sugalski [EMAIL PROTECTED] whispered:
| Doesn't it make more sense to get rid of arrays and just use hashes?
|
| I guess it depends on what you think makes sense; but it seems to me
| that an array is a more fundamental data type; that it's easier
Lightning flashed, thunder crashed and Dan Sugalski [EMAIL PROTECTED] whispered:
| At 04:03 PM 8/15/00 -0500, Jarkko Hietaniemi wrote:
| open, you fall through, someimes through several floors, until somewhere
| you encounter a safety net: you were caught. You can continue from
| there. If
Lightning flashed, thunder crashed and "Jeremy Howard" [EMAIL PROTECTED] whispered:
| @unzipped_list2 should not be([X,Y,Z], [A,B,C], [M]). The RFC's proposed
| behaviour makes it work as the inverse of zip(), which is the desired
| behaviour.
The reason I used letters instead of the actual
25 matches
Mail list logo
