On Fri, Oct 21, 2005 at 04:04:25PM -0600, Luke Palmer wrote:
: However, if I get my wish of having zip return tuples, then it can be
: left-associative. But since it interleaves instead, making it left-
: or right-associative gives strange, incorrect results.
I expect zip ought to bundle up into
On 10/21/05, Mark Reed <[EMAIL PROTECTED]> wrote:
> Hm. This brings up another point, which may have been addressed . . .
>
> The Python function and Ruby array method zip() both accept any number of
> arrays to interleave:
>
> >>> zip([1,2,3],[4,5,6],[7,8,9])
> [(1, 4, 7), (2, 5, 8), (3, 6, 9)]
>
On 10/6/05, Juerd <[EMAIL PROTECTED]> wrote:
> for @foo Y @bar Y @baz -> $quux, $xyzzy { ... }
>
> is something you will probably not see very often, it's still legal
> Perl, even though it looks asymmetric. This too makes finding the
> solution in arguments a non-solution.
Don't be silly. Th
Dave Whipp skribis 2005-10-06 9:57 (-0700):
> Given that my idea about using optional binding for look-ahead didn't
> fly, maybe it would work here, instead:
> @a Y @b -> $a, $b { ... } # stop at end of shortest
> @a Y @b -> $a, ?$b { ... } # keep going until @a is exhaused
> @a Y @b ->
On Thu, Oct 06, 2005 at 10:31:50AM -0600, Luke Palmer wrote:
> If we make zip return a list of tuples rather than an interleaved
> list, we could eliminate the final 1/3 of those errors above using the
> typechecker. That would make the for look like this:
>
> for @a Y @b -> ($a, $b) {...}
I
Luke Palmer wrote:
zip :: [a] -> [b] -> [(a,b)]
It *has* to stop at the shortest one, because it has no idea how to
create a "b" unless I tell it one. If it took the longest, the
signature would have looked like:
zip :: [a] -> [b] -> [(Maybe a, Maybe b)]
Anyway, that's just more of t
On 10/5/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> Luke wrote:
> > I'm just wondering why you feel that we need to be so careful.
>
> Because I can think of at least three reasonable and useful default behaviours
> for zipping lists of differing lengths:
>
> # Minimal (stop at first exhau
Luke wrote:
>>Once C stops zipping, if any other element has a known finite
>>number of unexhausted elements remaining, the fails.
>
> Wow, that's certainly not giving the user any credit.
Actually, I want to be careful because I give the users too much credit. For
imagination.
On 10/5/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> So I now propose that C works like this:
>
> C interleaves elements from each of its arguments until
> any argument is (a) exhausted of elements I (b) doesn't have
> a C property.
>
> Once C stops zipping, if any
David Storrs asked:
If you want a multiway zip with
differing fillins, can't you do this?
@foo = 1..10 ¥:fill(0) 'a'..c' ¥:fill('x') ¥ 1..50;
I don't think that works. For example, why does the :fill(0) of the first ¥
apply to the 1..10 argument instead of to the 'a'..'c' argument? Especia
On Oct 5, 2005, at 7:49 PM, Damian Conway wrote:
Providing a :fillin() adverb on C is a suboptimal solution,
because it implies that you would always want to fill in *any* gap
with the same value. While that's likely in a two-way zip, it seems
much less likely in a multiway zip.
I actual
I've been thinking about this issue some more and it occurs to me that we
might be thinking about this the wrong way.
Providing a :fillin() adverb on C is a suboptimal solution, because it
implies that you would always want to fill in *any* gap with the same value.
While that's likely in a two
I guess nobody mentioned this, so I don't know how people on perl-language
feel about 'do it the same was as ', but I took a small jump into
Haskell a while back (barely enough to consider myself a beginner), but even
after just a little bit of time with it, I think I'd almost expect the
default zi
Damian Conway skribis 2005-10-05 10:05 (+1000):
> I suspect that the dwimmiest default would be for C to stop zipping at
> the length of the shortest finite argument. And to fail unless all finite
> arguments are of the same length.
This is a nice compromise.
But what if you cannot know whethe
From: Luke Palmer <[EMAIL PROTECTED]>
Date: October 5, 2005 1:48:54 AM EDT
To: David Storrs <[EMAIL PROTECTED]>
Subject: Re: zip: stop when and where?
Reply-To: Luke Palmer <[EMAIL PROTECTED]>
On 10/4/05, David Storrs <[EMAIL PROTECTED]> wrote:
How about:
@foo = (&
On Tue, 4 Oct 2005, Eric wrote:
I'd just like to say that I find B a bit misleading because you couldn't
tell that the first list ended, it could just have undef's at the end. I
Well, OTOH undef is now a more complex object than it used to be, so there
may be cheap workarounds. Of course one
On 10/4/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> If that ends up being common, we could create a syntax for it, like
> postfix:<...>:
>
> @array... # same as (@array, undef xx Inf)
No, no, that's a bad idea, because:
@array...# same as @array.elems..Inf
So I think I'm pr
On 10/4/05, Juerd <[EMAIL PROTECTED]> wrote:
> What should zip do given 1..3 and 1..6?
>
> (a) 1 1 2 2 3 3 4 5 6
> (b) 1 1 2 2 3 3 undef 4 undef 5 undef 6
> (c) 1 1 2 2 3 3
> (d) fail
>
> I'd want c, mostly because of code like
>
> for @foo Y 0... -> $foo, $i { ... }
>
> Pugs currently does b.
Juerd wrote:
What should zip do given 1..3 and 1..6?
(a) 1 1 2 2 3 3 4 5 6
(b) 1 1 2 2 3 3 undef 4 undef 5 undef 6
(c) 1 1 2 2 3 3
(d) fail
I'd want c, mostly because of code like
for @foo Y 0... -> $foo, $i { ... }
Pugs currently does b.
I agree that C should have named options (perha
I see your point. Option b does suggest that you can read ahead in a
"blocked" list and get undef's. If I had to choose just one, I think
I'd opt for d, but having two zip's one acting like c and one like d
might be useful. Then, of course, my first thought was wrong. This one
may well be, too.
--
On Tue, Oct 04, 2005 at 09:00:15PM +0200, Juerd wrote:
> What should zip do given 1..3 and 1..6?
>
> (a) 1 1 2 2 3 3 4 5 6
> (b) 1 1 2 2 3 3 undef 4 undef 5 undef 6
> (c) 1 1 2 2 3 3
> (d) fail
>
> I'd want c, mostly because of code like
>
> for @foo Y 0... -> $foo, $i { ... }
>
> Pugs curr
Hey,
I'd just like to say that I find B a bit misleading because you couldn't
tell that the first list ended, it could just have undef's at the end. I
like a because it doesn't add any data that wasn't there, of course that
could be a reason to dislike it too. On the other hand c makes a good optio
That (b) certainly seems like the sensible option to me. My second
choice would be d.
A nice thing about c is that it leaves open the possibility of lazy
evaluation (zip as much of the lists as you can, leaving open the
possibility of picking up the process later). But I still prefer b.
Maybe ther
On 10/4/05, Juerd <[EMAIL PROTECTED]> wrote:
>
> What should zip do given 1..3 and 1..6?
>
> (a) 1 1 2 2 3 3 4 5 6
> (b) 1 1 2 2 3 3 undef 4 undef 5 undef 6
> (c) 1 1 2 2 3 3
> (d) fail
>
> I'd want c, mostly because of code like
>
> for @foo Y 0... -> $foo, $i { ... }
>
> Pugs currently does b.
On Mon, Aug 01, 2005 at 01:13:52PM +0200, "TSa (Thomas Sandlaß)" wrote:
: BTW, you didn't mean originally:
:
: say zip (@odd), (@even); # prints 13572468 or 12345678?
That doesn't work, since () in list context does not enforce scalar context.
It's exactly equivalent to
say zip @odd, @even
HaloO,
Luke Palmer wrote:
On 8/1/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
In general, (@foo, @bar) returns a new list with the element joined,
i.e. "@foo.concat(@bar)". If you want to create a list with two sublists,
you've to use ([EMAIL PROTECTED], [EMAIL PROTECTED]) or ([EMAIL PROTE
On 8/1/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
> In general, (@foo, @bar) returns a new list with the element joined,
> i.e. "@foo.concat(@bar)". If you want to create a list with two sublists,
> you've to use ([EMAIL PROTECTED], [EMAIL PROTECTED]) or ([EMAIL PROTECTED],
> [EMAIL PROTECTE
Hi,
TSa (Thomas Sandlaß orthogon.com> writes:
> Ingo Blechschmidt wrote:
> > say zip (@odd, @even); # &zip gets only one argument, the flattened
> > # list ( @odd, @even), containing the
>
> Why flattened? Shouldn't that be *(@odd, @even)?
IIUC:
say zip *(@o
HaloO,
Andrew Shitov wrote:
TTS> BTW, you didn't mean originally:
TTS>say zip (@odd), (@even); # prints 13572468 or 12345678?
That is exactly like with similar printing result of sub() call:
print sqrt (16), 5; # shout print 45.
That all hinges on the type of the symbol. I guess &s
HaloO,
Ingo Blechschmidt wrote:
Whitespace is significant:
say zip @odd, @even;# &zip gets two arguments, result is
# 12345678.
say zip(@odd, @even); # &zip gets two arguments, result is
# 12345678.
say zip (@odd, @even);
HaloO,
Andrew Shitov wrote:
Is it possible to avoid significance of whitespaces?
Yes, with:
say zip .(@odd, @even);
Looks like a method and *is* a method in my eyes.
First &zip is looked-up and then bound as block owner.
Arguments are of course two array refs to @odd and @even
respectively
Hi,
Andrew Shitov wrote:
> I tried zip under pugs.
>
> my @odd = (1, 3, 5, 7);
> my @even = (2, 4, 6, 8);
> my @bothA = zip @odd, @even;
> print @bothA;
>
> This code prints 12345678 as expected.
>
> After parenthesis were used to group zip arguments, results changes
> to 135724
Goplat wrote:
I have quite a few fonts, the only one I can find where | is a broken bar is
"Terminal", a font for DOS programs that uses the cp437 charset, which is
incompatable with latin1 (« and » are AE and AF instead of AB and BB) and it
dosen't even have a ¦. So, it dosen't seem like a proble
33 matches
Mail list logo
