Lightning flashed, thunder crashed and Larry Wall <[EMAIL PROTECTED]> whispered:
| Simon Cozens writes:
| : On Fri, May 04, 2001 at 04:42:07PM -0700, Nathan Wiger wrote:
| : > : while ($STDIN) { ... }
| : > I'm wondering what this will do?
| : >$thingy = $STDIN;
| : > This seems to have t
Lightning flashed, thunder crashed and "Brent Dax" <[EMAIL PROTECTED]> wh
ispered:
| $a.$b;
| a.$b;
|
| Unless we decide that objects can contain scalars
| and to access them you must prefix their name with $, the middle pair can't
| be object calls, so they're concat.
How about symbolic refs to
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 la
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";#
Lightning flashed, thunder crashed and Garrett Goebel <[EMAIL PROTECTED]> w
hispered:
| cmp ~<=>
| .= ~+=
| ~=+ (concat after)
| =~ =~
| !~ !~
It's not bad enough that we're getting a proliferation of trigraph
operators, now you w
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 sti
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 woul
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 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 =
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 re
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 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 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() t
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 C and C commands are legacy commands which have been
| > deprecated for at least 5 years. They should be removed from the languag
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 i
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 curr
I don't see these ideas in RFCs:
* The match operator, C, is always required (bare C becomes a fatal
error).
* Replace C with flag to C, and remove special meaning of C.
* Socket functions (such as C, C, etc) should be moved from
the core to modules/libraries.
* Math functions (such as C, C,
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 Perl6 RFC Librarian <[EMAIL PROTECTED]>
whispered:
| =head3 Well-Named Global Hashes And Keys
|
| For each collection of variables, a well-named pseudo-hash with
| well-named keys:
|
| $PERL_CORE{warnings} vs $^W
| $PERL_CORE{version}
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 i
Lightning flashed, thunder crashed and Perl6 RFC Librarian <[EMAIL PROTECTED]>
whispered:
| =head1 TITLE
|
| Eliminate the optional C for C 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 INTERNAL:: o
Lightning flashed, thunder crashed and Perl6 RFC Librarian <[EMAIL PROTECTED]>
whispered:
| =head1 TITLE
|
| Builtin: partition
|
| =head1 ABSTRACT
|
| It is proposed that a new function, C, be added to Perl.
| C would return @list broken into
| references to sub-lists, each one $list_size in
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 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 ab
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 chea
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 val
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
| > > 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 easi
Lightning flashed, thunder crashed and John Porter <[EMAIL PROTECTED]> whispered
:
| Here's a counter-proposal: throw out hashes as a separate internal
| data type, and in its place define a set of operators which treat
| (properly constructed) arrays as associative arrays. It's the
Doesn't it m
Lightning flashed, thunder crashed and Perl6 RFC Librarian <[EMAIL PROTECTED]>
whispered:
| =head1 TITLE
|
| Builtins: zip() and unzip()
|
[snip]
|
| its arguments. C would reverse this operation.
|
[snip]
|
| If the list to be unzipped is not an exact multiple of the partition size,
| the fin
31 matches
Mail list logo
