On Fri, 2004-03-26 at 15:20, Luke Palmer wrote:
> When writing Perl 5, I always find myself writing @{ more often than @$.
> Maybe it's just a bad habit that I don't tend to use a lot of
> intermediate variables.
Well, one of the big problems with Perl 5's dereferencing is that it's
painful to cr
Larry Wall writes:
> On Fri, Mar 26, 2004 at 09:41:23AM -0700, Luke Palmer wrote:
> : Is @{$foo} going away? More specifically, how do I write that map if
> : $baz is some more complex expression, and I don't want to use * (say I
> : want to adhere if map decides to change its signature to take a
On Fri, Mar 26, 2004 at 09:41:23AM -0700, Luke Palmer wrote:
: Okay, good. So this is correct:
:
: my $baz = @foo;
: @bar = map { ... } @$baz;
:
: (to be equivalent of mapping over @foo)?
Yes, that's correct.
: Is @{$foo} going away? More specifically, how do I write that map if
: $ba
Juerd writes:
> Larry Wall skribis 2004-03-25 12:33 (-0800):
> > On Thu, Mar 25, 2004 at 11:35:46AM -0800, Brent 'Dax' Royal-Gordon wrote:
> > : Larry Wall wrote:
> > : > say @bar.elems;# prints 1
> > : C? Not C?
> > It's just a "println" spelled Huffmanly.
>
> Can't we instead just hav
Larry Wall skribis 2004-03-25 12:33 (-0800):
> On Thu, Mar 25, 2004 at 11:35:46AM -0800, Brent 'Dax' Royal-Gordon wrote:
> : Larry Wall wrote:
> : > say @bar.elems; # prints 1
> : C? Not C?
> It's just a "println" spelled Huffmanly.
What happened to the principle that things that work
Larry Wall writes:
> : Also, how does the use of *$foo differ from @$foo here? Is the later
> : going away? (I'd think that horrible, for the same reason as above: C
> : is confusing because it's not always clear what you get when you *.)
>
> No, @$foo is not going away. You can write it that
On 2004-03-26 at 08:16:07, Larry Wall wrote:
> And "say" isn't in there because of APL or PHP. It's actually inspired
> by something worse in Ruby.
Presumably by "something worse" you mean "puts"? Not a great name, to
be sure, but it does have a venerable tradition behind it. :)
I do like ha
On Fri, Mar 26, 2004 at 08:59:36AM +0100, James Mastros wrote:
: Larry Wall wrote:
: >Yes, * was originally a no-op in list context, but I think now we can
: >use it to deref a list that would otherwise not interpolate itself.
: >It maps better onto how a C programmer thinks, and if in scalar
: >co
Larry Wall wrote:
Yes, * was originally a no-op in list context, but I think now we can
use it to deref a list that would otherwise not interpolate itself.
It maps better onto how a C programmer thinks, and if in scalar
context it also happens to defer the signature checking to use the
interpolated
On Thu, Mar 25, 2004 at 11:35:46AM -0800, Brent 'Dax' Royal-Gordon wrote:
: Larry Wall wrote:
: > say @bar.elems;# prints 1
:
: C? Not C?
It's just a "println" spelled Huffmanly.
Larry
Larry Wall wrote:
say @bar.elems; # prints 1
C? Not C?
--
Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
On Thu, Mar 25, 2004 at 08:42:53AM -0700, Luke Palmer wrote:
: Aaron Sherman writes:
: > More to the point is there ever a reason to want any array ref in list
: > context to NOT explode other than []? I can't think of any.
: >
: > push @a, $b
: >
: > Is it too non-obvious that if $b is an ar
Aaron Sherman writes:
> I would expect [] to force itself into scalar context anyway. Is there
> ever a reason to want otherwise? Clearly the entire point of [] is to
> create a scalar array ref from a list of arguments.
>
> More to the point is there ever a reason to want any array ref in list
>
On Tue, 2004-03-23 at 13:11, Goplat wrote:
> @(...) is the "list context" operator in S3. I hope array references won't
> explode in list context, that would be very annoying when making
> multi-dimentional arrays:
>
> @foo = ([1, 2], [3, 4]) # oops, would be (1, 2, 3, 4)
> @foo = ($([1, 2]
--- Smylers <[EMAIL PROTECTED]> wrote:
> Luke Palmer writes:
>
> > for @(@ranges[1]) -> $i {
>
> Oooh, where did that dereferencing syntax come from, using parens rather
> than braces?
@(...) is the "list context" operator in S3. I hope array references won't
explode in list context, that wo
Smylers wrote:
Luke Palmer writes:
for @(@ranges[1]) -> $i {
Oooh, where did that dereferencing syntax come from, using parens rather
than braces?
It isn't a dereferencing syntax--it's a context-forcing syntax (one I'm
intimately familiar with), which forces @ranges[1] into list context.
Wh
Luke Palmer writes:
> for @(@ranges[1]) -> $i {
Oooh, where did that dereferencing syntax come from, using parens rather
than braces?
Smylers
Austin Hastings writes:
> > ->Â @cp makes about as much sense as subÂ(@cp). C returns a
> > list of array references, right? So it binds each one to @cp (the right
> > of -> is a subroutine parameter list, remember?).
>
> Are you saying that subÂ(@cp) is not, in fact, an alias for C ?
>
> Anyw
> -Original Message-
> From: Luke Palmer [mailto:[EMAIL PROTECTED]
>
> Austin Hastings writes:
> > Before this gets simonized, let me add that this seems genuinely
> > useful: It provides a way of constructing a loop in a dimension that
> > is not really accessible, except via recursion.
Austin Hastings writes:
> Before this gets simonized, let me add that this seems genuinely
> useful: It provides a way of constructing a loop in a dimension that
> is not really accessible, except via recursion.
>
> Luke: Would that have to be
>
> for outer([EMAIL PROTECTED]) ->Â @cp {...}
>
> -Original Message-
> From: [EMAIL PROTECTED]
>
> [EMAIL PROTECTED] (Austin Hastings) writes:
> > Before this gets simonized, let me add that this seems
> genuinely useful: It provides a way of constructing a loop in a
> dimension that is not really accessible, except via recursion.
>
> Oh
[EMAIL PROTECTED] (Austin Hastings) writes:
> Before this gets simonized, let me add that this seems genuinely useful: It provides
> a way of constructing a loop in a dimension that is not really accessible, except
> via recursion.
Oh, it *is* useful, and it's extremely nice to know that someth
> -Original Message-
> From: Luke Palmer [mailto:[EMAIL PROTECTED]
>
...
> Using a permutations module I could make that shorter, but I figure that
> since we're already providing C to make looping easier, why not
> provide C (perhaps spelled Â)? The outer function would provide
>
Luke Palmer writes:
> Which is of course wrong.
>
> sub _outer_coro(@prev, @data) is coroutine
> {
> if (@data) {
> _outer_coro([ @prev, @data[0] ], @data[1...])
> }
> else {
> yield [EMAIL PROTECTED];
> }
> }
>
> sub outer([
Luke Palmer writes:
> I believe it could be programmed lazily. Like this:
>
> sub _outer_coro(*$first is context(Scalar),
> [EMAIL PROTECTED] is context(Scalar))
> is coroutine
> {
> if @rest {
> _outer_coro [EMAIL PROTECTED];
> }
I found myself writing a perl script today in which I did (I'll
perl6-ize it for sake of discussion):
for 98,99 -> $i {
for 0..255 -> $j {
# testing IP addresses with $i.$j
}
}
I was thinking about what would happen if I allowed the user to input
those ranges,
26 matches
Mail list logo
