On Tue, Aug 02, 2005 at 12:49:06PM +1000, Brad Bowman wrote:
> > 1. Asserted
> >
> > The usual case for Perl 6 functions, due to its default "Item"
> > signature for parameters. In the example below, I assume that ::*
> > cannot
> > be changed freely to do away with ::*IO at runtime.
> 1. Asserted
>
> The usual case for Perl 6 functions, due to its default "Item"
> signature for parameters. In the example below, I assume that ::* cannot
> be changed freely to do away with ::*IO at runtime. (If it could, then
> assertions won't be of much use in general.)
>
On Mon, 01 Aug 2005 22:08:52 +0300, Yuval Kogman
<[EMAIL PROTECTED]> wrote:
[...]
> On Mon, Aug 01, 2005 at 08:46:07 -0700, Greg Buchholz wrote:
>
>> Has any thought been given to using a concurrent garbage collector
>> for Perl6? Besides eliminating GC pauses (which in turn means less of a
On Mon, Aug 01, 2005 at 08:46:07 -0700, Greg Buchholz wrote:
> Has any thought been given to using a concurrent garbage collector
> for Perl6? Besides eliminating GC pauses (which in turn means less of a
> need for users to fiddle with the GC settings, and therefore a smaller
> chance of acci
LP> my $x = (1,2,3,4,5);
LP> Looks like an error more than anything else.
'Perl 6 and Parrot Essentials' think different ;-)
--
___
Andrew, [EMAIL PROTECTED]
___
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
HaloO,
Autrijus Tang wrote:
On Mon, Aug 01, 2005 at 03:16:50PM +0200, "TSa (Thomas Sandla�)" wrote:
sub equitype ( ::a $x, a $y) { ... }
That's not a bad idea at all. I rather like it. I'd just still like an
explicit type-unifying parens around ::a, just so people won't say
I try to m
David Formosa wrote:
> I can see advantages to both approches. All GC systems have a hit
> when they run, in some situations it would be nice to shift the hit to
> times when it doesn't mattor that much. For example a GUI app may
> delay the GC till when the user has been idle for a while.
On Mon, Aug 01, 2005 at 03:16:50PM +0200, "TSa (Thomas Sandla�)" wrote:
>sub equitype ( ::a $x, a $y) { ... }
That's not a bad idea at all. I rather like it. I'd just still like an
explicit type-unifying parens around ::a, just so people won't say
sub foo (::Int $x) { ... }
and acciden
HaloO,
Autrijus Tang wrote:
[..] For example, assuming argument types are unified in a single
phase, the example below does nothing useful:
sub equitype ((::a) $x, (::a) $y) { ... }
It won't not help even if we replace the implicit "does" with "of":
sub equitype ($x of (::a), $y of (:
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);
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.
--
___
Андр
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,
"TSa (Thomas Sandlaß)" wrote:
> Ingo Blechschmidt wrote:
>> Is this a bug in S29 or will this be feature removed from Perl 6
>> and you'll have to say (for example)
>>
>> use listops :mutating;
>> my @result = map { $_++; 42 } @array; # works now
>
> Why not just
>
> my @result =
HaloO,
Ingo Blechschmidt wrote:
Is this a bug in S29 or will this be feature removed from Perl 6
and you'll have to say (for example)
use listops :mutating;
my @result = map { $_++; 42 } @array; # works now
Why not just
my @result = map -> $_ is rw { $_++; 42 } @array; # works
Is it possible to avoid significance of whitespaces?
I think, such an aspect of Perl 6 would be awful.
IB> Whitespace is significant:
IB> say zip(@odd, @even);
IB> say zip (@odd, @even);
--
___
Andrew, [EMAIL PROTEC
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
Hi,
according to S29 [1], neither map nor grep allow mutation:
multi sub Perl6::Array::map (@values, Code $expression) returns Lazy
multi sub Perl6::List::map (Code $expression : [EMAIL PROTECTED]) returns
Lazy
multi sub Perl6::Array::grep (@values : Code *&test ) returns
> FWIW, I've been reading up on Scala's formulation of trait/class/delegation
> hierarchy, and I feel a bit like flipping through a puzzle book to look
> at the hints, if not answers. :-)
>
> http://scala.epfl.ch/docu/files/api/index.html
I misread "mutable" as "mumble" and thought they'd be
21 matches
Mail list logo
