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 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
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
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 after f
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}.()))
((f
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 wrong?
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 I
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* know
what
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..6
Damian Conway skribis 2005-10-05 10:05 (+1000):
I suspect that the dwimmiest default would be for Czip 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
I guess nobody mentioned this, so I don't know how people on perl-language
feel about 'do it the same was as language', 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
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 this list,
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).continue(42)
Whow,
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 innocent
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
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 Czip 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
On Oct 5, 2005, at 7:49 PM, Damian Conway wrote:
Providing a :fillin() adverb on Czip 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
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?
On 10/5/05, Damian Conway [EMAIL PROTECTED] wrote:
So I now propose that Czip works like this:
Czip interleaves elements from each of its arguments until
any argument is (a) exhausted of elements Iand (b) doesn't have
a Cfill property.
Once Czip stops
Luke wrote:
Once Czip stops zipping, if any other element has a known finite
number of unexhausted elements remaining, the zip 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
29 matches
Mail list logo
