Luke Palmer <[EMAIL PROTECTED]> writes:
> On 6/14/05, Piers Cawley <[EMAIL PROTECTED]> wrote:
>> Following a conversation with Chip on IRC, is this
>>
>> my @y := @foo[0..][1];
>>
>> legal?
>
> Definitely not. But it sure would be nice if this:
>
> my @y := @foo[0...][1];
>
> were.
I t
On 6/14/05, Piers Cawley <[EMAIL PROTECTED]> wrote:
> Following a conversation with Chip on IRC, is this
>
> my @y := @foo[0..][1];
>
> legal?
Definitely not. But it sure would be nice if this:
my @y := @foo[0...][1];
were.
Luke
Following a conversation with Chip on IRC, is this
my @y := @foo[0..][1];
legal?
On Tue, Apr 19, 2005 at 02:14:04AM +0300, wolverian wrote:
: On Mon, Apr 18, 2005 at 04:00:53PM -0700, Larry Wall wrote:
: > %num_of_lines = [EMAIL PROTECTED];
: >
: > : because the Perl 5 way would put a reference to @file in the hash.
: > : Scalar context always makes references now, from wh
On Mon, Apr 18, 2005 at 04:00:53PM -0700, Larry Wall wrote:
> %num_of_lines = [EMAIL PROTECTED];
>
> : because the Perl 5 way would put a reference to @file in the hash.
> : Scalar context always makes references now, from what I understand.
>
> Interestingly, a stored reference would track t
On Mon, Apr 18, 2005 at 06:44:55PM -0400, Kurt Hutchinson wrote:
: On Mon, Apr 18, 2005 at 11:23:34PM +0300, Roie Marianer wrote:
: > That makes sense, but that would make
: > %num_of_lines = @file
: > not DWIM... of course that would translate into
: > %num_of_lines = scalar @file
: > so maybe t
On Mon, Apr 18, 2005 at 11:23:34PM +0300, Roie Marianer wrote:
> That makes sense, but that would make
> %num_of_lines = @file
> not DWIM... of course that would translate into
> %num_of_lines = scalar @file
> so maybe that's OK.
In order to promote proper syntactical thinking, note that this is
On Mon, Apr 18, 2005 at 11:23:34PM +0300, Roie Marianer wrote:
: > : But when you start interpolating, you get into a big mess:
: > : h<\qq[$interpolated]> = want(); # ???
: > : h<<$foo>> = want(); # ???
: >
: > I think that, as with functions called in unknown context, we should
: > just force t
> : But when you start interpolating, you get into a big mess:
> : h<\qq[$interpolated]> = want(); # ???
> : h<<$foo>> = want(); # ???
>
> I think that, as with functions called in unknown context, we should
> just force the RHS here to list context, and rely on the RHS to add
> extra context as
David Christensen wrote:
I definitely like the hyper stuff how it is; maybe the answer is to
just define an infix:<[[]]> operator which returns the crosswise slice
of a nested list of lists. In any case it could be shunted aside to
some package and certainly does not need to be in core.
Didn't
On Sun, Apr 17, 2005 at 08:00:00PM -0700, Brent 'Dax' Royal-Gordon wrote:
: Larry Wall <[EMAIL PROTECTED]> wrote:
: > : First, context of hash slices:
: > : Hash slices with {} notation are trivially either scalars or lists:
: > : $h{'foo'} = want(); # S
Larry Wall <[EMAIL PROTECTED]> wrote:
> : First, context of hash slices:
> : Hash slices with {} notation are trivially either scalars or lists:
> : $h{'foo'} = want(); # Scalar
> : $h{'foo','bar'} = want(); # List
>
> Right.
Tangentiall
On Sun, Apr 17, 2005 at 07:54:18PM +0300, Roie Marianer wrote:
: Hi all,
: I'm back with more quoting construct madness.
Kewl, d00d.
: First, context of hash slices:
: Hash slices with {} notation are trivially either scalars or lists:
: $h{'foo'} = want(); # Scalar
: $h{
I definitely like the hyper stuff how it is; maybe the answer is to
just define an infix:<[[]]> operator which returns the crosswise slice
of a nested list of lists. In any case it could be shunted aside to
some package and certainly does not need to be in core.
David
my @transposed = @matrix>
David Christensen writes:
> Quick thought ---
>
> Does the current design of Perl 6's hyper operators allow for
> "hyper-slices"? I.e., if I want to model a matrix by using a list of
> lists, is the following code valid/useful?
>
> my @matrix=([1,2,3],[4,5,6
Hi all,
I'm back with more quoting construct madness.
First, context of hash slices:
Hash slices with {} notation are trivially either scalars or lists:
$h{'foo'} = want(); # Scalar
$h{'foo','bar'} = want(); # List
With <> notation the same thing h
Quick thought ---
Does the current design of Perl 6's hyper operators allow for
"hyper-slices"? I.e., if I want to model a matrix by using a list of
lists, is the following code valid/useful?
my @matrix=([1,2,3],[4,5,6],[7,8,9]);
my @row = @matrix[0]; # first row
my @col = @matr
On Tue, Mar 22, 2005 at 05:18:44PM +0100, Thomas Sandlaß wrote:
: Rod Adams wrote:
: > multi sub postcircumflex::<[ ]>(MyArray $obj : [EMAIL PROTECTED]) is rw
{...}
: >
: >but I'll wait for S14 before speculating further.
:
: Will that ever be written? And if yes, will it be like S13 which
: is b
Rod Adams wrote:
multi sub postcircumflex::<[ ]>(MyArray $obj : [EMAIL PROTECTED]) is rw {...}
but I'll wait for S14 before speculating further.
Will that ever be written? And if yes, will it be like S13 which
is basically saying that overloading is subsumed by A12/S12?
I see the 'does' operator a
Luke Palmer <[EMAIL PROTECTED]> wrote:
> > Can I use slice notation when dealing with strings?
> >
> >say $string[-1]; # say substr($string, -1);
> >$string[0..2] = "Hello";
>
> No. I'm pretty sure that's the Right Thing, too. First, the "sixth
> element" in a string depends on how you'r
array and hash slices constantly in Perl 5. I would be
shocked if Perl 6 did not support doing the same. One of the things I
point to non-Perl people about why I like Perl over other languages is a
statement like (p5) C< @b{keys %a} = values %a; >, and then explain what
it does, and how it&
Matt Diephouse writes:
> Is it possible to assign to an array slice?
>
> @array[0..4] = ( 0..4 ); # splice @array, 0, 5, 0..4
Of course. You could in Perl 5, right?
> If so (and I'm hoping it is), is there an equivalent of Ruby's `[]=`
> method? (Is there a way to define this behavior within
Is it possible to assign to an array slice?
@array[0..4] = ( 0..4 ); # splice @array, 0, 5, 0..4
If so (and I'm hoping it is), is there an equivalent of Ruby's `[]=`
method? (Is there a way to define this behavior within my own
array-like classes?)
Can I use slice notation when dealing with st
Hmmm... David, you seem to have covered all the issues with that rather
lucid screed [attached at bottom]. I have a couple of dragon-nits to pick,
one involving infrastructure and one involving syntax.
First: it seems strange to me to add yet another property ("but
used_to_be_scalar") to t
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Green) wrote:
>I can imagine "table context" being reasonably popular. [...]
>(Taking a scalar and returning a list is less common, but I can
>imagine a 2-D version of 'split' that turns a string into a table)
One way to generalise i
OK, so at issue is the difference between an element of an array ($p5[1])
and a slice (that might contain only one element, @p5[1]), only
generalised to n dimensions. (A problem which didn't exist in P5 because
there were no higher dimensions!)
And we don't want @B[4; 0..6] to reduce to a 1-
On Tuesday 11 January 2005 10:06 pm, Dave Whipp wrote:
> We know that
>
> @a = (1, 2, 3);
> $b = @a[1];
>
> Loses the dimension as a DWIM.
>
> So perhaps we could say that assigning to a lower dimension always gets
> rid of a dimension of size 1 -- or error if it can't:
>
> @c = ( 1,2,3 ; 4,5,6 );
Larry Wall wrote:
On Sat, Jan 08, 2005 at 11:37:06AM -0700, Craig DeForest wrote:
: Is the perl6 expression
: @a[4; 0..5];
: a 1x6 array (probably correct)? Or a 6 array (probably not correct)?
Certainly the former. I don't think dimensions should ever disappear
accidentally.
Except when y
Craig DeForest skribis 2005-01-10 15:56 (-0700):
> @array[0..10; 42!; @x] [[ maps to ]] (<== [0..10], 42 , [EMAIL
> PROTECTED] );
@array[0..10; 1.40500611775288e+51; @x]? ;-)
Juerd
Double hmmm That would also supplant the lone '*' wart in indexing
syntax: instead of saying
@array[0..10;*;@x]
you could say
@array[0..10; !; @x]
Presumably, the '!;' would expand to the scalar undef value, which could be
interpreted as "do nothing on this axis", while in
H... It would be easy to distinguish the slicing cases if it were easier
to distinguish between a number and a list containing just [In fact, that is
more or less how perl5/PDL's arg-list-based slicer ('mslice') does things.]
At the top of Synopsis 9, there's a discussion about exactly that:
Sorry, too terse :-)
I meant "...a two dimensional array with 1x6 elements (probably correct)? Or
a one dimensional array with 6 elements (probably not correct)?"
Cheers,
Craig
Quoth David Storrs on Monday 10 January 2005 08:33 am,
> On Sat, Jan 08, 2005 at 11:37:06AM -0700, Craig DeForest wr
On Sat, Jan 08, 2005 at 11:37:06AM -0700, Craig DeForest wrote:
: I just re-read Synopsis 9, which covers PDL-related actions and array
slicing,
: and came to the conclusion that either (A) there's a hole in the syntax as it
: is lain out, (B) I lack sufficient understanding of what has been th
6 elements..?
On Mon, 10 Jan 2005 07:33:11 -0800, David Storrs <[EMAIL PROTECTED]> wrote:
> On Sat, Jan 08, 2005 at 11:37:06AM -0700, Craig DeForest wrote:
>
>
> > @a[4; 0..5];
> > a 1x6 array (probably correct)? Or a 6 array (probably not
> > correct)?
>
> For the ignorant among us (su
On Sat, Jan 08, 2005 at 11:37:06AM -0700, Craig DeForest wrote:
> @a[4; 0..5];
> a 1x6 array (probably correct)? Or a 6 array (probably not
> correct)?
For the ignorant among us (such as myself), what is a 6 array? Google
and pdl.perl.org did not yield any immediate answers.
--Dks
--
range is a 1x3-array
$a->range($xy,[0,3]);# This perl5/PDL range is a 3-array
The extra parens only remove the dimension if they would otherwise be no-ops.
It is not (yet) clear to me whether the extra parens syntax is a good solution
for perl 6 slices.
Rod Adams writes:
> Come the glorious age of Perl6, will hash slices be enhanced to allow
> things like the following?
>
> [EMAIL PROTECTED]'expected'} = [EMAIL PROTECTED];
Well, you can always do this:
[EMAIL PROTECTED] = [EMAIL PROTECTED];
But I definite
Come the glorious age of Perl6, will hash slices be enhanced to allow
things like the following?
[EMAIL PROTECTED]'expected'} = [EMAIL PROTECTED];
Specifically, having the slice be something other than the last element.
This likely dictates having {} be able access a list of of has
1', +'2', +'3', +'4', +'5');
>
> And since everything is a constant, you end up with:
>
> int @matrix = (1, 2, 3, 4, 5);
>
This int business may make sense for a one dimensional array, but I meant
@matrix to be 2 dimensional, and he
On Thu, 2004-04-15 at 18:23, Austin Hastings wrote:
> > @matrix... = <<1 0 0 1>>;
> Keep in mind that you're using a quoting operator. For numbers, you can just
> use (0, 1, 2, 3)
> and probably be better understood. (The <> approach will
> work, but it will take all the numbers through a str
Austin Hastings writes:
>
>
> > -Original Message-
> > From: Abhijit A. Mahabal [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, 15 April, 2004 05:13 PM
> > To: [EMAIL PROTECTED]
> > Subject: Array/Hash Slices, multidimensional
> >
> >
>
> -Original Message-
> From: Abhijit A. Mahabal [mailto:[EMAIL PROTECTED]
> Sent: Thursday, 15 April, 2004 05:13 PM
> To: [EMAIL PROTECTED]
> Subject: Array/Hash Slices, multidimensional
>
>
> As the hash syntax is being worked out, I thought it'd be a good t
As the hash syntax is being worked out, I thought it'd be a good time to
ask if the following will be supported in some form:
If I have some structure like %foo{"monday"}, %foo{"tuesday"} etc,
I can set their values enmass using:
%foo<> = <>;
What if I had
%foo{"monday"}{"food_ex
y syntax ideas for this at the moment.
We already have the concept of contexts (list, scaler, bool, etc.). SO
we can start with the concept of "index context" (list-index context
for slices). In index context, we could define "*" as a special token
that returns the highest index
BL> $bar = (@foo[1], @foo[2], @foo[3]);
the real problem with perl slices is that there is no special syntax
associated with the array/hash that is parse specially as a slice. so
you can't use 3 .. -1 to get what you want. .. is just an expression
operator and perl doesn't see it
On Thu, 24 May 2001 22:19:12 -0400, James Mastros wrote:
>But what about: @foo[(1,2,3)]?
>
>Are those parens a list-maker, or are they a scalar expression using
>the comma operator.
Both.
But in this case, I'd say: it depends on the context the slice is called
in.
@bar = @foo[(1,2,3)]
First off, sorry about the noise -- I expect that Larry will have this
mostly worked out already. [And, when I re-read Apocalypse 2, I saw
that I had almost literally stolen some of his sentences. *blush*]
On Thu, May 24, 2001 at 10:19:12PM -0400, James Mastros wrote:
> But what about: @foo[(1,2
From: "Raul Miller" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, May 24, 2001 7:49 PM
Subject: slices
> First: @a[@(...)] looks plausible as a slice syntax. Or -- if you
> specify an array value as an index, shouldn't that be a slice?
I like your
Caution: I'm not yet up to speed on everything perl6. However, I've
dealt with stuff like slices in a variety of non-perl contexts, and
maybe I'll propose some questions which no one has brought up, yet.
First: @a[@(...)] looks plausible as a slice syntax. Or -- if you
specify
David M. Lloyd wrote:
> $a = ($obj1, $obj2)->method;# Unclear. Calling in scalar context
> # gives no benefit, since you will
> # still have 2 return values. Maybe call
> # methods in list context
Paul Johnson wrote:
> David M. Lloyd wrote:
>
> > $obj->method; # Clearly void context.
>
> Unless it's not. For example as the last statement in a subroutine.
Right. Context means context! Just because there's no context-
inducing code on this line, doesn't mean there isn't somewhere
On Mon, Mar 26, 2001 at 10:02:40AM -0600, David M. Lloyd wrote:
> $obj->method; # Clearly void context.
Unless it's not. For example as the last statement in a subroutine.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
-- Forwarded message --
Date: Mon, 26 Mar 2001 08:16:24 -0600 (CST)
From: David M. Lloyd <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: Perl 5 Porters <[EMAIL PROTECTED]>
Subject: Re: Distributive -> and indirect slices
On Mon, 26 Mar 2001 [EMAIL PROTECTED] wrote:
>
Simon Cozens wrote:
>
> On Mon, Mar 19, 2001 at 08:30:31AM -0800, Peter Scott wrote:
> > Seen http://dev.perl.org/rfc/82.pod?
>
> I hadn't. I'm surprised it didn't give the PDL people screaming fits.
> But no, I wouldn't do it like that. It has:
>
> @b = (1,2,3);
> @c = (2,4,6);
> @d = @b *
Simon Cozens wrote:
> Better is to solve the general problem, and have all
> operators overloadable even on non-objects, so the user
> can define how this sort of thing works.
Even better is to let the user have access to the real
objects by which "non-objects", i.e. normal variables,
are impleme
On Mon, Mar 19, 2001 at 08:30:31AM -0800, Peter Scott wrote:
> Seen http://dev.perl.org/rfc/82.pod?
I hadn't. I'm surprised it didn't give the PDL people screaming fits.
But no, I wouldn't do it like that. It has:
@b = (1,2,3);
@c = (2,4,6);
@d = @b * @c; # Returns (2,8,18)
Where I would h
At 03:18 PM 3/19/01 +, Simon Cozens wrote:
>That's not really nuts. Really nuts would be suggesting that all operators
>should distribute:
>
> @a = ($foo, $bar) . $baz # @a = map { $_.$baz } ($foo, $baz)
>
>Mmmm. I could get to like that.
Seen http://dev.perl.org/rfc/82.pod?
--
Peter
On Mon, Sep 25, 2000 at 06:33:07PM +1100, Jeremy Howard wrote:
> Can we extend RFC 282 so that it allows the right operand of C<..> to be
> omitted in any index, since the upper-bound can be implied? Or does it
> already propose this?
Yes, I wanted this to apply to all slices.
> =head1 TITLE
>
> Open-ended slices
>
<...>
>
> @thingy = function()
> for (@thingy[3..$#thingy]) { ... }
>
> Horrible, isn't it? People want something better.
>
> I thought about it last year or so, and produced a couple of patches. It
>
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Open-ended slices
=head1 VERSION
Maintainer: Simon Cozens <[EMAIL PROTECTED]>
Date: 24 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 282
Version: 1
Status: Developing
=head1 ABSTRAC
60 matches
Mail list logo
