surprised and pleased to find that I could apparently subscript
> > an array with a list of lists of indices, and get a list of slices back:
> >
> > > my @array = 9 ... 0
> > [9 8 7 6 5 4 3 2 1 0]
> > > @array[map { $_, $_ + 1 }, ^9]
> > ((9 8) (8 7) (7 6)
Feels like worthy of making an issue for this to me.
> On 16 Aug 2019, at 12:18, Sean McAfee wrote:
>
> Today I was surprised and pleased to find that I could apparently subscript
> an array with a list of lists of indices, and get a list of slices back:
>
> > my @array =
Today I was surprised and pleased to find that I could apparently subscript
an array with a list of lists of indices, and get a list of slices back:
> my @array = 9 ... 0
[9 8 7 6 5 4 3 2 1 0]
> @array[map { $_, $_ + 1 }, ^9]
((9 8) (8 7) (7 6) (6 5) (5 4) (4 3) (3 2) (2 1) (1 0))
Neat
# New Ticket Created by Zoffix Znet
# Please include the string: [perl #131280]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=131280 >
You can give a nested slice as a list and get the result similarly nested,
however, this
Now fixed in 2c9f46f. Needs spectests to close ticket.
Thanks,
Pm
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #112362]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org:443/rt3/Ticket/Display.html?id=112362 >
masak: I think there's also an unsubmitted rakudobug in
today's backlog, kind of
# New Ticket Created by Paweł Pabian
# Please include the string: [perl #75636]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=75636 >
Erlangen build:
# testing with Array
perl6 -e 'my @t=1,2; my %h; %...@t}="one","two"; s
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
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Px = Py[Pz]
> won't be, and we'll need to note whether Pz should be taken as an
> int, string, or PMC. (PMC for the fancier keying of hashes)
> ... A simple :i, :s, :p [...] suffix
Do we really need that? The aggregate is responsible to do the righ
Michael Fischer <[EMAIL PROTECTED]> wrote:
> On Jun 18, Leopold Toetsch <[EMAIL PROTECTED]> took up a keyboard and banged out
>> Piter = slice Pagg[ 1 .. 4, 7, 10 .. ]
>>
>> (The space between a number and ".." is needed, the lexer would parse
>> "1." as a float - workarounds welcome)
> if th
On Jun 18, Leopold Toetsch <[EMAIL PROTECTED]> took up a keyboard and banged out
> Slice iterators for arrays[1] and PerlStrings are working now.
>
> 1) create a slice iterator
>
> Piter = slice Pagg[ 1 .. 4, 7, 10 .. ]
>
> (The space between a number and ".." is needed, the lexer would par
Single slice values for PerlHash are functional too.
PIter = slice Phash["a", "b", "c"]
For slice ranges we probably need the perl5ish string increment and
decrement of strings.
leo
Slice iterators for arrays[1] and PerlStrings are working now.
1) create a slice iterator
Piter = slice Pagg[ 1 .. 4, 7, 10 .. ]
(The space between a number and ".." is needed, the lexer would parse
"1." as a float - workarounds welcome)
2) Reset iterator
PIter = .ITERATE_FROM_START
3) Loo
On Tue, 15 Jun 2004, Dan Sugalski wrote:
> So, given that, should plain scalars act as iterators holding a single
> value and implement the iterator protocol?
That'd be messy if two things tried to take an iterator over the same scalar
as the same time. On the other hand if it created an iterator
Dan Sugalski wrote:
Yeah, but given that this code will be generated by compilers 90+% of
the time... the assembly generation and parsing of the assembly's easier
with the postfix notation.
My understanding is that compilers will generate an AST, not textual
PIR. Thus, we are looking for a nota
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 10:06 AM -0700 6/16/04, Brent 'Dax' Royal-Gordon wrote:
>>Dan Sugalski wrote:
>>>Which reminds me--we need to have a syntax to distinguish between key types.
>>
>>Perl already gives us two of the three:
>> Px[Iy]
>> Px{Sy}
>>
>>For the third, I
At 7:48 PM +0200 6/16/04, Eirik Berg Hanssen wrote:
Dan Sugalski <[EMAIL PROTECTED]> writes:
At 10:06 AM -0700 6/16/04, Brent 'Dax' Royal-Gordon wrote:
Dan Sugalski wrote:
Which reminds me--we need to have a syntax to distinguish between
key types.
Perl already gives us two of the three:
Px[
At 10:06 AM -0700 6/16/04, Brent 'Dax' Royal-Gordon wrote:
Dan Sugalski wrote:
Which reminds me--we need to have a syntax to distinguish between key types.
Perl already gives us two of the three:
Px[Iy]
Px{Sy}
For the third, I suggest we extend the analogy:
Px
Except it breaks really re
Dan Sugalski wrote:
Which reminds me--we need to have a syntax to distinguish between
key types.
Perl already gives us two of the three:
Px[Iy]
Px{Sy}
For the third, I suggest we extend the analogy:
Px
--
Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
Oceania has a
At 11:25 AM +0200 6/16/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
*) We consider ways to make slices. I can see ops, or I can see basic
functions. Either is fine, depends on how often the things are used.
I'll start from the end of the proposal. What about jus
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> *) We consider ways to make slices. I can see ops, or I can see basic
> functions. Either is fine, depends on how often the things are used.
I'll start from the end of the proposal. What about just extending the
keyed synta
Okay, before we go any further, I think it's important to note that
we're going to restrict ourselves to unidimensional slices for the
time being. Yes, I know, we probably need to deal with
multidimensional slices at some point (and I say probably since there
are quite a number of
ike:
> >>
> >> @foo[0..2,4..8,12..];
> >>
> >> with three entries in the slice array--one with a from/to of 0/2, one
> >> with 4/8, and one with 12/inf.
> >
> >Perl also has:
> >
> >@foo[0..12 :by(3)]# 0,3,6,9,12
> >
> >PD
of 0/2, one
with 4/8, and one with 12/inf.
Perl also has:
@foo[0..12 :by(3)]# 0,3,6,9,12
PDL has affine slices.
Yeah, but at some point you have to draw the line and say "This is as
far as we're going at the low level."
Iterators have the advantage over arrays since they
> with 4/8, and one with 12/inf.
Perl also has:
@foo[0..12 :by(3)]# 0,3,6,9,12
PDL has affine slices.
To me, it seems like the best thing to do is to give slice an iterator,
and slice would return an iterator that maps keys to values. So, doing
C<@bar = @foo[0..2,4..8,12...]
Since we're going to need these, and I'm in a documenting and
defining mood (yes, I am making a final decision on strings today.
Whee!) I figure we need to tackle them.
First, slices. Perl's got 'em, Python has them, Ruby, interestingly,
doesn't. (Sort of) A slice is a
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
Ilya Zakharevich wrote:
> On Sun, Oct 01, 2000 at 08:51:04AM +1100, Jeremy Howard wrote:
> > Please no! Anything that makes it harder to write 'quick-and-dirty'
scripts
> > is never going to fly--this is part of what makes Perl special.
>
> Why? I see no problem in making -Mstrict and -Wall the d
On Sun, Oct 01, 2000 at 08:51:04AM +1100, Jeremy Howard wrote:
> > > A prototypeless-function call.
> > >
> > get rid of them all!!
>
> Please no! Anything that makes it harder to write 'quick-and-dirty' scripts
> is never going to fly--this is part of what makes Perl special.
Why? I see no pro
Karl Glazebrook wrote:
> Ilya Zakharevich wrote:
> > On Thu, Sep 28, 2000 at 11:39:51AM -0400, Karl Glazebrook wrote:
> > > > > so what is wrong with the statement '@y = 3*@x;' then ?
> > > >
> > > > That other constructs *also* create an array context, in which the
> > > > behaviour of multiplica
get rid of them all!!
Ilya Zakharevich wrote:
>
> On Thu, Sep 28, 2000 at 11:39:51AM -0400, Karl Glazebrook wrote:
> > > > so what is wrong with the statement '@y = 3*@x;' then ?
> > >
> > > That other constructs *also* create an array context, in which the
> > > behaviour of multiplication you
On Thu, Sep 28, 2000 at 11:39:51AM -0400, Karl Glazebrook wrote:
> > > so what is wrong with the statement '@y = 3*@x;' then ?
> >
> > That other constructs *also* create an array context, in which the
> > behaviour of multiplication you propose is not appropriate.
>
> for example?
A prototypel
Ilya Zakharevich wrote:
> > so what is wrong with the statement '@y = 3*@x;' then ?
>
> That other constructs *also* create an array context, in which the
> behaviour of multiplication you propose is not appropriate.
for example?
> I did not see any viable proposal on changing things in a majo
On Mon, Sep 25, 2000 at 06:30:22PM -0400, Karl Glazebrook wrote:
> > Well, this shows that you entirely miss the problem of cryptocontexts.
> > Context is determined by the "environment" of the operation, not by
> > the operation. Context is propagated:
> >
> > the-left-hand-side-of-assignment
Ilya Zakharevich wrote:
>
> On Sat, Sep 23, 2000 at 11:32:58AM -0400, Karl Glazebrook wrote:
> > Yes this is the point. I guess another way of looking at it is
> > saying that 3*@a operates in a list context not a scalar context
>
> Well, this shows that you entirely miss the problem of cryptoco
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
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Arrays: New operator ';' for creating array slices
=head1 VERSION
Maintainer: Jeremy Howard <[EMAIL PROTECTED]>
Date: 8 Sep 2000
Last Modified: 24 Sep 2000
Mailing List: [EMAIL PRO
On Sat, Sep 23, 2000 at 11:32:58AM -0400, Karl Glazebrook wrote:
> Yes this is the point. I guess another way of looking at it is
> saying that 3*@a operates in a list context not a scalar context
Well, this shows that you entirely miss the problem of cryptocontexts.
Context is determined by the
[EMAIL PROTECTED] wrote:
>
> Ilya Zakharevich wrote:
> > ...Do you say you are confused by using vectors (=scalars) instead of
> > arrays?
>
> I'm not having a problem with that personally but *many* users of PDL
> have complained about being confused by this.
> They assume ndim == array == perl
Ilya Zakharevich wrote:
>
> On Sat, Sep 23, 2000 at 10:41:07AM +1100, Jeremy Howard wrote:
> > Many Perl users operate on lists of data. Requiring explicit loops every
> > time a programmer wants to operate on a list is asking the programmer to fit
> > in with how a computer thinks. That's not r
Ilya Zakharevich wrote:
>
> On Fri, Sep 22, 2000 at 05:24:55PM -0400, Karl Glazebrook wrote:
> > It's now boiling down to a matter of opinion and we'll have to agree to
> > differ. Of course I use array arithmetic all the time as a heavy PDL
> > user.
>
> ...Do you say you are confused by using
On Sat, Sep 23, 2000 at 10:41:07AM +1100, Jeremy Howard wrote:
> > a) You can *already* use vectors as scalars in Perl;
>
> That's not what RFC 82 is proposing.
Who cares? This already works...
> > b) What we are discussing is Perl, not Mathematica, J, PDL, and so
> >forth. These language
Ilya Zakharevich wrote:
> Are you trying to convince me/us that is going to be used often?
>
Yes, I am. You made the unsupported statement that array operations are
rarely used. I'm suggesting otherwise (although to say that they're rarely
used in Perl 5 is a tautology, of course!).
> > Array not
On Sat, Sep 23, 2000 at 10:01:11AM +1100, Jeremy Howard wrote:
> > It's now boiling down to a matter of opinion and we'll have to agree to
> > differ. Of course I use array arithmetic all the time as a heavy PDL
> > user.
> It's not just for number-crunchers either. Array notation greatly simplif
Karl Glazebrook wrote:
> Ilya Zakharevich wrote:
> > You are trading a frequently used shortcut @a == 1 + $#a for a
> > rarely-used-but-beautiful/intuitive semantic. I'm not sure it is a win.
>
> It's now boiling down to a matter of opinion and we'll have to agree to
> differ. Of course I use arr
1 - 100 of 124 matches
Mail list logo
