Both Luke and I missed the fact that my mail and his response went
only to each other so, with his permission, here it is as a forward.
--Dks
Begin forwarded message:
From: Luke Palmer <[EMAIL PROTECTED]>
Date: October 5, 2005 1:48:54 AM EDT
To: David Storrs <[EMAIL PROTECTED]>
Subject: Re:
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
Perl 6 Summary for 2005-09-26 through 2005-10-02
All~
Welcome to another summary, this time a day late because I was in Philly
for Serenity. If you haven't seen Serenity yet you should stop reading
this summary and go see it. The summary will be here when you get back.
I promis
Rafael Garcia-Suarez <[EMAIL PROTECTED]> wrote:
> So, such a "sensitive" modifier could be added, but its
> precise meaning would be highly dependent on the underlying
> implementation.
Okay, but there needs to be some minimum standard for it, like "the
memory in question no longer contains its or
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.
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
--
http://convolution.nl/maak_juerd_blij.html
http://con
On Tue, 4 Oct 2005, Rafael Garcia-Suarez wrote:
language like C. So, such a "sensitive" modifier could be added, but its
precise meaning would be highly dependent on the underlying
implementation.
It would be of interest more to a perl programmer than to a Perl
programmer. Like keys() as an l
Brent 'Dax' Royal-Gordon wrote in perl.perl6.language :
> Basically, I'd like to be able to mark a variable as "sensitive" or
> "secret". This implies that the language should overwrite the memory
> it uses before deallocating it, and that if possible it should tell
> the virtual memory system to
14 matches
Mail list logo
