Nathan Wiger wrote:
Juerd wrote:
Nathan Wiger skribis 2005-04-25 13:35 (-0700):
My point is simply that we pick one or the other, instead of
both/aliases/etc.
But TIMTOWTDI. One way may be great for writing maintainable code, while
the other is useful in oneliners (including single line method
def
Juerd wrote:
Nathan Wiger skribis 2005-04-25 13:35 (-0700):
My point is simply that we pick one or the other, instead of
both/aliases/etc.
But TIMTOWTDI. One way may be great for writing maintainable code, while
the other is useful in oneliners (including single line method
definitions).
Then I su
Nathan Wiger writes:
> Paul Seamons wrote:
> >>> meth foo {
> >>>$_.meth; # defaults to the invocant
> >>>.meth; # operates on $_ which defaults to the invocant
> >>>$^.meth; # is the invocant
> >>>$^1.meth; # is the first invocant
> >>>$^2.meth; # is the second invocant
> >>
>
Nathan Wiger skribis 2005-04-25 13:35 (-0700):
> My point is simply that we pick one or the other, instead of
> both/aliases/etc.
But TIMTOWTDI. One way may be great for writing maintainable code, while
the other is useful in oneliners (including single line method
definitions).
Juerd
--
http:/
Juerd writes:
> (While typing this, I realised that there may be, in English, a
> difference between subject and topic. If that's true, please educate
> me.)
Well, from a non-linguist's point of view, they are two very different
things.
My brother asked me to take out the trash. I asked him
Paul Seamons wrote:
meth foo {
$_.meth; # defaults to the invocant
.meth; # operates on $_ which defaults to the invocant
$^.meth; # is the invocant
$^1.meth; # is the first invocant
$^2.meth; # is the second invocant
I'm starting to get confused at the "need" for all these sp
Juerd writes:
> Which assumptions are wrong?
>
> foo (3) + 4;# foo(7)
> foo(3) + 4; # foo(3)
> foo.(3) + 4;# foo(3)
> foo .(3) + 4; # foo(3)
>
> $foo (3) + 4; # syntax error
> $foo(3) + 4;# $foo(3)
> $foo.(3) + 4; # $foo(3)
> $foo .(3) + 4
Juerd writes:
> Assuming the following are true:
>
> A: "if" is now a normal function
Almost. It's a statement-level form, which looks like a normal function
except for the statement: prepended on its name. Such constructs (which
include for, while, the whole gang) have a few special proper
On Tue, Apr 26, 2005 at 03:33:44AM +0800, Autrijus Tang wrote:
> Another quick check on expression context for indexed expressions.
> Please sanity-check the return value of want() below:
>
> @x[0] = want(); # scalar context
> @x[want()] = $_; # scalar context
> @x[want()] = @_; #
Rod Adams skribis 2005-04-25 14:37 (-0500):
> There will always be various control constructs that cannot be written
> as an equivalent function. Otherwise, there is no way to write the
> higher level ones.
Not a problem, because we're using something to bootstrap, and the perl
6 you'll be using
Juerd wrote:
Assuming the following are true:
A: "if" is now a normal function
B: "foo() + 3" is (foo) + 3, foo doesn't get 3.
Then does that mean we're stuck with:
C: "if($foo) { say 'foo' }" being a syntax error?
I currently think A is wrong. Am I right?
Juerd
There will always be var
Another quick check on expression context for indexed expressions.
Please sanity-check the return value of want() below:
@x[0] = want(); # scalar context
@x[want()] = $_; # scalar context
@x[want()] = @_; # scalar context
@x[0,] = want(); # list context
@x[want(),] = $_; #
Which assumptions are wrong?
foo (3) + 4;# foo(7)
foo(3) + 4; # foo(3)
foo.(3) + 4;# foo(3)
foo .(3) + 4; # foo(3)
$foo (3) + 4; # syntax error
$foo(3) + 4;# $foo(3)
$foo.(3) + 4; # $foo(3)
$foo .(3) + 4; # $foo(3)
$o.m (3) + 4; #
Paul Seamons skribis 2005-04-25 13:02 (-0600):
> method foo ($self:) {
>return grep { $self.is_ok( .value ) } $self.info_pairs;
># .value called on the topic $_
> }
I think that to be fair, you have to leave out the redundant $self
there.
return grep { $self.is_ok( .value ) } .info_pa
Assuming the following are true:
A: "if" is now a normal function
B: "foo() + 3" is (foo) + 3, foo doesn't get 3.
Then does that mean we're stuck with:
C: "if($foo) { say 'foo' }" being a syntax error?
I currently think A is wrong. Am I right?
Juerd
--
http://convolution.nl/maak
> > meth foo {
> > $_.meth; # defaults to the invocant
> > .meth; # operates on $_ which defaults to the invocant
> > $^.meth; # is the invocant
> > $^1.meth; # is the first invocant
> > $^2.meth; # is the second invocant
>
> I'm starting to get confused at the "need" fo
Paul Seamons wrote:
So then, to get back to the invocant... I can't say that I liked many of the
proposals. The one that seemed to have merit though was $^. I'd propose the
following.
meth foo {
$_.meth; # defaults to the invocant
.meth; # operates on $_ which defaults to the invo
I think it would be great to be able to use a junction with use:
use strict & warnings;
A disjunction could mean any of the listed modules suffices. This comes
in handy when you code something that will work with any of three XML
parsers. Although because ordering matters, the // operator is
Thomas Sandlaß skribis 2005-04-25 19:13 (+0200):
> I think your basic error in perception is that $_ is a runtime variable
> while the invocant(s) are more a design time assumption of what the
> method is working on.
$_ is the *topic*. Its role in design and thinking is gigantic.
The funny thing
Thomas Sandlaß skribis 2005-04-25 19:30 (+0200):
> .method sqrt: # $?SELF.method( $_.sqrt() )
I don't like your solution simply because I don't like indirect object
calls. I avoid to and want to continue to avoid them, and do want a
short way for $_. Besides that, I think whatever default
Paul Seamons skribis 2005-04-25 11:12 (-0600):
> By this reasoning - why have a shortcut to any of the invocants at all? This
> thread has headed in the direction of finding a way to figure out how to call
> methods on the invocant without using the signatures name. On a method call
> without
Paul Seamons wrote:
method foo {
for 1 .. 10 {
$^.method(.sqrt);
}
}
I would make that:
method foo
{
for 1 .. 10
{
.method sqrt: # $?SELF.method( $_.sqrt() )
}
}
Then usage is:
my $x = "blubb";
$x.foo; # $x.method( sqrt(1) ) .. $x.method( sqrt(10) )
Iff "blubb" has go
Paul Seamons wrote:
> Yes, I know there "can be" a "way back." In this thread, none of the
> examples give one using existing Perl 6 syntax. They are all proposing new
> ways. This is one more.
Sorry if this sounded brash. I have a habit of not figuring out that there is
more of the message to
Juerd wrote:
However, the discussion is about changing these simple, clear, and
useful rules to a more complex situation of choosing a default based on
what the default will be used for, making the default for methods the
invocant rather than $_. I hate those plans and would love to see the
current
> What is this "way back" you repeatedly mention?
>
> If it is having a name for the invocant, then there has always been one:
>
> method foo ($self:) {
> for (1..10) {
> $self.method(.sqrt)
> }
> }
>
> Or, well, two:
>
> method foo {
> my $self := $_
David Storrs skribis 2005-04-25 10:00 (-0700):
> Cool. But that seems to turn off all warnings during the compilation
> of the expression--I only want to get rid of the (expected)
> 'uninitialized' warning. Will there be a way to do finer-grained
> control?
compile("no warnings :undef; $exp
On Mon, Apr 25, 2005 at 05:18:11AM -0600, Luke Palmer wrote:
> David Storrs writes:
> > sub foo {
> > my ($x,$y) = @_;
> > note("Entering frobnitz(). params: '$x', '$y'");
> > ...
> > }
> > This, of course, throws an 'uninitialized value in concatenation or
> > string' warni
Steven Philip Schubiger skribis 2005-04-25 18:44 (+0200):
> I confess, it's likely a bad habit, to coin it "array context" on
> p6l, although it refers to Perl 5, where it I have seen it more than
> once - perhaps, overly abused too.
That's old Perl5-ese. There was a big jargon change when people
Paul Seamons skribis 2005-04-25 9:52 (-0600):
> a way back
What is this "way back" you repeatedly mention?
If it is having a name for the invocant, then there has always been one:
method foo ($self:) {
for (1..10) {
$self.method(.sqrt)
}
}
Or, well, two:
On 25 Apr, Juerd wrote:
: I don't know how it's called on other levels, but we're still calling
: that list|slurpy|plural context. "array context" looks too much like
: "Array context", which is something else.
I confess, it's likely a bad habit, to coin it "array context" on
p6l, although it ref
Larry Wall wrote:
Depends on whether the user is actually expecting equal MMD there,
or tie-breaking between multi methods within the particular class.
My gut-level feeling is that they expect the latter.
With combined .method and method: syntax we also could have a nice
top priority or innermost s
I think the original (or the "latest original") reason for breaking .meth from
meaning $_.meth is that $_ is transitory and there was no way back to the
nameless invocant. In the absense of having a way back, I and others
strongly advocated breaking the link. I think we hated to do it.
Now i
Brad Bowman wrote:
my $a = rand(); # runtime variable
my $result = one(any( sub { $a+1}, sub { $a-1} ),sub { $a+3 }).();
say $result.perl;
If $a was 0.5 I'd guess
$result = one(any(1.5, 0.5), 3.5)
is this the case?
IIRC the .perl method produces a string from which an equal value
can be re
Larry Wall wrote:
I should point out that we're still contemplating breaking .foo() so it
no longer means $_.foo(). I wish there were more keys on my keyboard...
What is the status of my proposal to reserve the indirect object syntax
for calls on $_ and the .method form for the invocant in (single
David Storrs writes:
> I image we've all written logging code that looks something like this
> (Perl5 syntax):
>
> sub foo {
> my ($x,$y) = @_;
> note("Entering frobnitz(). params: '$x', '$y'");
> ...
> }
>
> This, of course, throws an 'uninitialized value in concatenation
Steven Philip Schubiger skribis 2005-04-25 5:41 (+0200):
> That was to be expected, as it's no language-design specific issue,
> and therefore, unsuitable for p6l.
> : print ++$i, $i++; # 3 2
> You're misleaded here, by thinking, scalar context is being enforced,
> which is not the case; the resul
On Sun, Apr 24, 2005 at 04:39:04PM -0700, Larry Wall wrote:
> : Larry suggested that to keep it from being collapsed, we somehow
> : augment toplevel AST:
> :
> : map { $_ => $_; } @foo;
> : map { +($_ => $_) } @foo;
>
> Uh, I'm not sure what + would return for a Pair, but I'm pretty sure
That puts my mind at ease!
Many thanks,
Carl
On 4/25/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> Carl Franks writes:
> > Will it be valid to pass a hash to a subroutine expecting named
> > params, if the hash keys match the names?
> >
> > sub do_this (+$foo, +$bar) {
> > # whatever
> > }
> >
Carl Franks writes:
> Will it be valid to pass a hash to a subroutine expecting named
> params, if the hash keys match the names?
>
> sub do_this (+$foo, +$bar) {
> # whatever
> }
>
> %arg = (
> :foo,
> :bar,
> );
>
> do_this(*%arg);
Yep, and that's exactly how you do it, too. I believe
Will it be valid to pass a hash to a subroutine expecting named
params, if the hash keys match the names?
sub do_this (+$foo, +$bar) {
# whatever
}
%arg = (
:foo,
:bar,
);
do_this(*%arg);
I use this technique a lot, and it would be unfortunate to miss out on
the advantages of subroutine s
On 21 Apr, fayland wrote:
: It has been published at perl6.language, but have no reply.
That was to be expected, as it's no language-design specific issue,
and therefore, unsuitable for p6l.
: In perl v5.8.6 built for MSWin32-x86-multi-thread:
:
: my $i = 1;
: print $i++, ++$i; # 1 3
: my $i =
41 matches
Mail list logo
