Using semicolons is an interesting idea. But consider:
@a[10:20; 30:40];
The ":"s and ";" are awfully hard to visually distinguish.
c.f.
@a[10:20, 30:40];
What do people feel about the whole replacing ".." by ":"
issue?
Karl
Consider
@x[10:20, 20:40:2, 30:50]
This ALMOST works in the current Perl. @x gives array context,
then the , produces a list.
If [] is overloaded on @a then the subroutine sees a list like
"10:20", "20:40:2", "30:50"
The only reason it does NOT work in the current perl is that "10:20"
is a s
At 10:48 AM 8/28/00 -0400, Karl Glazebrook wrote:
>Using semicolons is an interesting idea. But consider:
>
>@a[10:20; 30:40];
>
>The ":"s and ";" are awfully hard to visually distinguish.
True, but @a[10..20; 30..40]; isn't hard to distinguish.
Even so, you might get such things as:
@a[10..20
Karl, all: I have just been auditing this list so far ;)
But I would like to speak up in support of Baris' idea. I have long
found it
confusing (both to myself and to those I must explain my code to) the
mix of
pdl multi-dimensional lists (lists of refs to lists) and PDLs, which
appear to be sc
Doug Hunt wrote:
> But I would like to speak up in support of Baris' idea. I have long
> found it
> confusing (both to myself and to those I must explain my code to) the
> mix of
> pdl multi-dimensional lists (lists of refs to lists) and PDLs, which
> appear to be scalars. I was even asked once
Christian: You are right, it would not be best to confuse normal perl
lists with compact arrays--they both have their purposes and can be
combined usefully.
What I meant to say (but failed, alas) was that I support the idea for a
new perl variable type called compact array:
$foo -- scalar
@foo
Doug Hunt wrote:
> What I meant to say (but failed, alas) was that I support the idea for a
> new perl variable type called compact array:
>
> $foo -- scalar
> @foo -- array
> %foo -- hash
> ^foo -- compact array (or whatever notation)
I seem to remember that ^ was in the process of being hig
> > ^foo -- compact array (or whatever notation)
>
> I seem to remember that ^ was in the process of being highjacked by some
> other RFC already. Was it higher-order functions?
Yes: RFC 23 (v4): Higher order functions
Damian
Dan Sugalski wrote:
> >
> >I'm thinking that a n-dim array could just be a list of lists (of lists of
> >lists of...) with the n-dim notation just being syntactic sugar (and perhaps
> >helping with optimisation too).
>
> If you want efficiency, n-dimensional arrays really need to be a concrete
>
Karl Glazebrook wrote:
>
> Consider
>
> @x[10:20, 20:40:2, 30:50]
>
> This ALMOST works in the current Perl. @x gives array context,
> then the , produces a list.
I see a number of problems with the current (scalar) PDL objects being
turned (essentially) into perl arrays in perl6.
1) How do y
First of all, apologies for my lack of input over the last
week--unfortunately I went on holidays pretty much as this list went online,
so I've been pretty quiet. Anyhow, for those who don't know me, I'm the
chair of perl6-language-data. For the remainder of its existance I'll be
more active.
Thi
Doug Hunt wrote:
>
> What I meant to say (but failed, alas) was that I support the idea for a
> new perl variable type called compact array:
>
> $foo -- scalar
> @foo -- array
> %foo -- hash
> ^foo -- compact array (or whatever notation)
>
> Given this notation, you could have hashes of compa
Christian Soeller wrote:
>
> The other problem with arrays is: how do we deal with functions that
> take multiple piddle arguments if they are arrays:
>
>@result = integrate @x, @y, @bounds;
>
> Won't those all be clumped into one big input array?
This should be overrideable by prototypes.
> I think the better way is to take Buddha's idea (soon to be RFC'ed, by
> the sounds of it), and make current arrays a little more flexible. It
> sounds like we'll just have to add an extra dimension somehow, and then
> "arrays of compact arrays" will simply be "arrays with some compact
> elemen
Buddha Buck wrote:
> > I think the better way is to take Buddha's idea (soon to be RFC'ed, by
> > the sounds of it), and make current arrays a little more flexible. It
> > sounds like we'll just have to add an extra dimension somehow, and then
> > "arrays of compact arrays" will simply be "arrays
Jeremy Howard wrote:
> Basically, I want to be able to create a list ref of list refs, specify a
> data type (eg 'int') and attributes of ':compact' or ':sparse', and have the
As Dan Sugalski suggested it seems not a good idea to bring in the list
of list ref into the proposal. Why does it have
At 10:28 AM 8/28/00 +1000, Jeremy Howard wrote:
>
>
>David L. Nicol wrote:
> > If arrays as we know them implement by using a key space restricted to
> > integers, I think a reasonable way to get matrices would be to open
> > up their key space to lists of integers.
> >
>I've been thinking along e
Dan Sugalski wrote:
> If you want efficiency, n-dimensional arrays really need to be a concrete
> data type all of their own. That way one big block of memory can be
> allocated and, if it's a typed array, properly sized.
I wholeheartedly agree ;)
>
> That doesn't mean that n-dimensional array
At 08:18 AM 8/29/00 +1200, Christian Soeller wrote:
>Dan Sugalski wrote:
> > That doesn't mean that n-dimensional arrays won't be just sugar over the
> > standard list-o-list structure to start, but they won't have to stay
> that way.
>
>That seems to be a possible route. Get multi-dim syntax for
19 matches
Mail list logo
