A06 says:
If you |shift| or |pop| without an argument, it shifts or pops whatever
slurpy array is in scope.
Shall we assume that @_ is always an alias for this array, so I can say
something like:
multi sub pop (Array [EMAIL PROTECTED] = @caller::_) returns Scalar
?
btw, is ?@ legal in a signat
How am I supposed to define a signature that says "A scalar that refers
to a hash or array element, but do not evaluate or autovivify the element"?
Or are these two are now strictly methods without functional forms?
-- Rod Adams
Leopold Toetsch wrote:
Rod Adams <[EMAIL PROTECTED]> wrote:
While that's a nice feature to have in general, I feel better about
going ahead and predefining that the builtins are already members of
Num, Str, Array, Hash for the shear performance and documentation values
of it.
That's exactly
On Mon, Mar 14, 2005 at 04:15:35PM +0100, Thomas Sandlaß wrote:
: Hmm, since "what is compile to you is runtime for the compiler"
: it might by a normal store attempt that is then rejected by the object
: and caught by the compiler---cool. Is there also an unchecked store
: operation that can be u
Larry Wall writes:
> The Principle of Maximum Differentiation of Similar Constructs also
> tends to argue for eager =. Plus there's the fact that it's the sort
> of restriction we can relax if we figure out how, but it would be hard
> to impose if people started to rely on lazy assignment and then
On Mon, Mar 14, 2005 at 07:04:12PM +0100, Thomas Sandlaß wrote:
: Yep. Does that put =, := etc into a category of operators that
: are hard to (usefully) overload in classes? I mean the eager =
: doesn't look like letting the left and right hand side have much
: to do or decide in the process---oth
On Mon, Mar 14, 2005 at 12:16:13PM -0600, Rod Adams wrote:
: Therefore, as I go through S29, I'll assign all functions to some
: module. I'll be using the P5/CPAN hierarchy as a strong guideline.
:
: We can then discuss what gets bound into ::*, and when, at some later
: point in time.
That's a
Larry Wall wrote:
On Mon, Mar 14, 2005 at 08:10:15AM -0600, Patrick R. Michaud wrote:
: I ran into this problem while creating a mini-list of S29 functions
: (which Rod's work supercedes, I suspect, and I'm very glad he's taking
: this on). What are some guidelines we could use in deciding
: whic
: Given this Pugs program, t.p6:
:
: my $fh = open(@ARGS[0]);
: my @lines = =$fh;
: $fh.close();
: for @lines { print"$_" }
:
: running:
:
: pugs t.p6 t.p6
:
: produces no output. Move $fh.close() to after the for
: loop and all is well. Is this a bug?
I wonder if IO::All could provide some inspira
Larry Wall wrote:
The Principle of Maximum Differentiation of Similar Constructs also
tends to argue for eager =. Plus there's the fact that it's the sort
of restriction we can relax if we figure out how, but it would be hard
to impose if people started to rely on lazy assignment and then we
decid
On Mon, Mar 14, 2005 at 06:00:11PM +0100, Thomas Sandlaß wrote:
: BTW, I'm unsure how packages, modules and classes roles interact with
: the type system and MMD. In particualr what can be put into the type slot
: of declarations/definitions:
:
: my SomeThing $x;
:
: Can SomeThing be a package? A
The Principle of Maximum Differentiation of Similar Constructs also
tends to argue for eager =. Plus there's the fact that it's the sort
of restriction we can relax if we figure out how, but it would be hard
to impose if people started to rely on lazy assignment and then we
decided it was a bad id
On Mon, Mar 14, 2005 at 09:52:06AM -0700, Luke Palmer wrote:
: Perhaps lists by assignment are COW lazy. So they behave just like
: ordinary COW objects, except they can be lazy at the end:
:
: my @a = gather {
: for 1... {
: say;
: take
On Tue, Mar 15, 2005 at 12:21:19AM +0800, Autrijus Tang wrote:
: On Mon, Mar 14, 2005 at 08:06:08AM -0800, Larry Wall wrote:
: > On Mon, Mar 14, 2005 at 10:58:00PM +1100, Andrew Savige wrote:
: > : my $fh = open(@ARGS[0]);
: > : my @lines = =$fh;
: > : $fh.close();
: > : for @lines { print"$_" }
:
Luke Palmer wrote:
&cos($angle) or Degrees::cos($angle), depending on whether you
defined it your way or my way. Uh oh, I thought we were going to make
single-invocant multis and methods the same everywhere...
Sorry for messing up the syntax in my example code. What I wanted to achieve
is to get a
On Mon, Mar 14, 2005 at 08:10:15AM -0600, Patrick R. Michaud wrote:
: I ran into this problem while creating a mini-list of S29 functions
: (which Rod's work supercedes, I suspect, and I'm very glad he's taking
: this on). What are some guidelines we could use in deciding
: which functions are au
Autrijus Tang writes:
> On Mon, Mar 14, 2005 at 08:06:08AM -0800, Larry Wall wrote:
> > On Mon, Mar 14, 2005 at 10:58:00PM +1100, Andrew Savige wrote:
> > : my $fh = open(@ARGS[0]);
> > : my @lines = =$fh;
> > : $fh.close();
> > : for @lines { print"$_" }
> > :
> >
> > Hmm. It's probably a desig
On Mon, Mar 14, 2005 at 05:28:29PM +0100, Miroslav Silovic wrote:
> But it gets worse.
>
> my $lines = [ =$fh ];
> seek($fh, 0);
> my $lines2 = [ =$fh ];
> close $fh;
>
> $lines2 must somehow remember that seek has happened.
That is fine because the three thunks are registered to the fh
in evalu
On Mon, Mar 14, 2005 at 08:06:08AM -0800, Larry Wall wrote:
> On Mon, Mar 14, 2005 at 10:58:00PM +1100, Andrew Savige wrote:
> : my $fh = open(@ARGS[0]);
> : my @lines = =$fh;
> : $fh.close();
> : for @lines { print"$_" }
> :
>
> Hmm. It's probably a design bug. I'm wondering if we have to spec
On Mon, Mar 14, 2005 at 10:58:00PM +1100, Andrew Savige wrote:
: Given this Pugs program, t.p6:
:
: my $fh = open(@ARGS[0]);
: my @lines = =$fh;
: $fh.close();
: for @lines { print"$_" }
:
: running:
:
: pugs t.p6 t.p6
:
: produces no output. Move $fh.close() to after the for
: loop and all is
Thomas Sandlaà writes:
> Rod Adams wrote:
> >And then internally dispatch on what is defined and undefined.
>
> Why all that burden if Perl 6 is getting a strong type system,
> that can do the sub selection and compile in dynamic dispatch if
> needed?
>
> I imagine:
>
> multi sub cos( Num +$angl
Juerd wrote:
Larry Wall skribis 2005-03-11 8:45 (-0800):
On Fri, Mar 11, 2005 at 03:58:13PM +0100, Thomas Sandlaß wrote:
: Int @i;
: Num @n = @i; # type error?
I think the naive user is going to expect that to work, and I also
suspect the naive user is right to expect it, because it makes sense.
T
Patrick R. Michaud skribis 2005-03-14 8:10 (-0600):
> I ran into this problem while creating a mini-list of S29 functions
> (which Rod's work supercedes, I suspect, and I'm very glad he's taking
> this on). What are some guidelines we could use in deciding
> which functions are automatically in
On Sun, Mar 13, 2005 at 06:03:20PM -0800, Larry Wall wrote:
> : One thing I've already done is make a list of Perl 5 functions I cannot
> : address until some future Apocalypse/Synopsis is generated on the topic.
> : By far the bulk of this list falls on S16. Partly because IPC is a mess,
> : an
Rod Adams wrote:
And then internally dispatch on what is defined and undefined.
Why all that burden if Perl 6 is getting a strong type system,
that can do the sub selection and compile in dynamic dispatch if
needed?
I imagine:
multi sub cos( Num +$angle ) returns Num where { -1.0 <= $_ <= 1.0 }
cla
[EMAIL PROTECTED] wrote:
for [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] -> $x { say $x };
should work. Are there any non-slashy versions of this?
I'd guess
for @a; @b; @c -> $x { say $x;}
or
for (@a; @b; @c) -> $x { say $x;}
(are parens mandatory here?)
Miro
Rod Adams <[EMAIL PROTECTED]> wrote:
> While that's a nice feature to have in general, I feel better about
> going ahead and predefining that the builtins are already members of
> Num, Str, Array, Hash for the shear performance and documentation values
> of it.
That's exactly the plan, when it co
Rod Adams wrote:
I have the philosophical problem with your use of junctions in this
context due to the fact that you are completely ignoring the predicate
of the junction. The C< all(...) == one(...) > is an excellent use of
YES, and much clearer than when this test is buried under code
that ha
On Mon, Mar 14, 2005 at 01:07:45AM -0600, Rod Adams wrote:
: It's been defined that Perl 6.0.0 does not dispatch on named parameters,
: for better or for worse. If you don't like it, talk to Larry.
That's a little bit of an overstatement. I've only said 6.0.0 doesn't
*have* to support MMD on nam
Will there be a way to achieve what the Carp module does in perl 6? I
like the functionality it gives me, but think that it should be
builtin. Perhaps it could work like this:
caller.throw('an error');
Could this:
throw('an error');
just be another way to say:
$?BLOCK.throw('an error');
30 matches
Mail list logo
