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 Oct 5, 2005, at 1:17, Matt Fowles wrote:
Here Doc in PIR
Will Coleda revived a thread from February about PIR here doc
syntax.
Looks like the syntax is ok.
Jonathan Worthington has already implemented here doc syntax.
Data::Escape::String Dislikes Unicode
Will noticed
Playing with pugs, I ran into this corner case:
sub f($x) { say $x; }
f {1}.(); # ok, outputs 1
sub f([EMAIL PROTECTED]) { say @_; }
f {1}.(); # outputs block, tries to call a method from the return of say,
dies
Whitespace after f doesn't change the behaviour (in either case). Is this
behaviour
Brent 'Dax' Royal-Gordon wrote in perl.perl6.language :
>
> I would like "is sensitive" to be defined to mean that any data stored
> in that variable, at any level of recursion, will be zeroed out as
> soon as it is garbage collected. Particular implementations can add
> extra features on top of t
Brent,
Why not post the original query to p6compiler for their take on it?
Carl
On 10/4/05, Miroslav Silovic <[EMAIL PROTECTED]> wrote:
> Playing with pugs, I ran into this corner case:
>
> sub f($x) { say $x; }
> f {1}.(); # ok, outputs 1
>
> sub f([EMAIL PROTECTED]) { say @_; }
> f {1}.(); # outputs block, tries to call a method from the return of say,
> dies
>
> Whitespace
HaloO,
Luke Palmer wrote:
On 10/4/05, Miroslav Silovic <[EMAIL PROTECTED]> wrote:
Playing with pugs, I ran into this corner case:
sub f($x) { say $x; }
f {1}.(); # ok, outputs 1
IIRC, this puts f into the named unary precedence level
which is below method postfix. Thus we get
(f ({1}.())
On 10/5/05, TSa <[EMAIL PROTECTED]> wrote:
> IIRC, this puts f into the named unary precedence level
> which is below method postfix.
We're trying to stop using the words "below" and "above" for
precedence. Use "looser" and "tighter" instead, as there is not
ambiguity with those.
>(f ({1}.()
HaloO,
Luke Palmer wrote:
On 10/1/05, David Storrs <[EMAIL PROTECTED]> wrote:
All in all, I think that might just be the end of the tunnel up
ahead. Go us for getting here, and loud applause to @Larry for
guiding us so well!
Applause for p6l for hashing out the issues that we didn't think
Luke Palmer wrote:
With parentheses:
print((length "foo") < 4)
print(3 < 4)
So this was quite a disturbing bug.
This is now also quite a fixed bug. :-)
However:
f:{1}.()
still parses as
(&f(:{1})).()
as the "adverbial block" form takes precedence. Is that also wro
On Mon, Oct 03, 2005 at 22:58:28 -0700, Brent 'Dax' Royal-Gordon wrote:
> For the last couple days, I've been implementing a cryptographic
> cipher framework for Perl 6. (It's in the Pugs repository if you want
> to see it.) Dealing with this sort of algorithm has brought forward a
> feature that
On Mon, 26 Sep 2005 20:17:05 +0200, TSa wrote:
> Piers Cawley wrote:
> >>Exactly which exception is continued?
> > The bottommost one. If you want to return to somewhere up its call
> > chain, do:
> >
> > $!.caller(n).continue(42)
>
> Whow, how does a higher level exception catcher *in general* k
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 = ('a', 'b', 'c');
for @foo ¥ 1
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
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
On Wed, 2005-10-05 at 16:26 +0200, TSa wrote:
> > I recently wrote a "Perl 6 design TODO", which was surprizingly small,
> > which enumerated the things to be done before I considered the design
> > of Perl 6 to be finished. Larry replied with a couple more items.
>
> The type system is not on t
On Wed, Oct 05, 2005 at 16:57:51 +0100, Peter Haworth wrote:
> On Mon, 26 Sep 2005 20:17:05 +0200, TSa wrote:
> > Piers Cawley wrote:
> > >>Exactly which exception is continued?
> > > The bottommost one. If you want to return to somewhere up its call
> > > chain, do:
> > >
> > > $!.caller(n).cont
On 10/5/05, Autrijus Tang <[EMAIL PROTECTED]> wrote:
> However:
> f:{1}.()
>
> still parses as
>
> (&f(:{1})).()
>
> as the "adverbial block" form takes precedence. Is that also wrong?
No, that seems right to me, much in the same way that:
$x.{1}.{2}
Binds to the left.
Luke
On 10/5/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 05, 2005 at 16:57:51 +0100, Peter Haworth wrote:
> > On Mon, 26 Sep 2005 20:17:05 +0200, TSa wrote:
> > > Whow, how does a higher level exception catcher *in general* know
> > > what type it should return and how to construct it? The
Apocalypse 12 has the following to say about roles and trust
(http://www.perl.com/pub/a/2004/04/16/a12.html?page=10)
It's not clear whether roles should be allowed to grant
trust. In the absence of evidence to the contrary, I'm
inclined to say not.
In Perl 5, I recently found myself in the
Luke Palmer wrote:
Of course, exactly how this "public interface" is declared is quite undefined.
Reading this thread, I find myself wondering how a resumable exception
differs from a dynamically scropted function. Imagine this code:
sub FileNotWriteable( Str $filename ) {
die "can't write
On 10/5/05, Ovid <[EMAIL PROTECTED]> wrote:
> sub _attributes {
> my ($self, $attrs) = @_;
> return $$attrs if UNIVERSAL::isa( $attrs, 'SCALAR' );
>
> my @attributes = UNIVERSAL::isa( $attrs, 'HASH' )
> ? %$attrs : @$attrs;
> return unless @attributes;
> # more code here
--- Luke Palmer <[EMAIL PROTECTED]> wrote:
> sub _attributes($ref) {
> my multi attributes ($scalar) { $$scalar }
> my multi attributes (@array) { @array }
> my multi attributes (%hash) { %hash }
> attributes($ref)
> }
>
> That attributes look suspiciously
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
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
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 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
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.
28 matches
Mail list logo
