In Perl 5, "caller EXPR" returns undef if the caller is top-level code. If
you need it, you can still get file, line, and package information
(this last is important for "import" subs) by using "caller" with the
EXPR-less form.
How do you do that in Perl 6? I'd been working with this presumed
sign
On 6/17/05 10:56 PM, David Storrs wrote:
> I'm not fond of .:: because I don't think it's sufficiently visually
> distinct from .:.
Hm, let's look at it:
method total(...)
{
.::sanity_check();
return .:value_one() + .:value_two();
}
Maybe lined up?
.::internal_value(
On Jun 17, 2005, at 10:42 PM, John Siracusa wrote:
But the truth is that /
really does look file-path-y to me, and just plain old ugly. I
think at
least two other people had similar reactions (Martin Kuehl and Carl
Franks).
David Storrs, reporting to show solidarity, sir(acusa)!
Maybe .:
Oops, part of Diamian's quoted text got trimmed accidentally in my last
post. It should have looked like this:
On 6/17/05 10:42 PM, John Siracusa wrote:
> [...] I'm not, however, buying Damian's argument here:
>
> On 2005-05-15 20:33:19, [EMAIL PROTECTED] (Damian Conway) said:
>> This missing d
(Yes, the subject line is a ps joke...it's late...well, late for a new
parent, anyway.)
On 6/17/05 6:18 PM, Damian Conway wrote:
> John Siracusa wrote:
>> (BTW, I'm not sure where those "./" thingies came from, but it's what GMail
>> showed in your message. I'm assuming it should just be ".")
>
John Siracusa wrote:
Wow, that..er...how did I miss that? It looks a lot like running an
executable in the current dir instead of letting the shell search its path.
That's the mnemonic, yes. Call this functionality relative to the current
"location" (i.e. invocant).
Was this syntax discu
Abhijit Mahabal asked:
Er, is it true that methods don't topicalize the invocant nowadays?
If it's not true, it darn well ought to be!
I had thought that they do and one needs the ./ to still talk about the
invocant if some inner loop stole the $_, and until such stealing occurs
.foo() and
On 6/17/05 6:18 PM, Damian Conway wrote:
> John Siracusa wrote:
>> (BTW, I'm not sure where those "./" thingies came from, but it's what GMail
>> showed in your message. I'm assuming it should just be ".")
>
> No. There's now also a unary ./ operator in Perl 6.
>
> Unary . calls a specified meth
On Sat, 18 Jun 2005, Damian Conway wrote:
John Siracusa wrote:
(BTW, I'm not sure where those "./" thingies came from, but it's what
GMail
showed in your message. I'm assuming it should just be ".")
No. There's now also a unary ./ operator in Perl 6.
Unary . calls a specified method on
On Sat, Jun 18, 2005 at 08:18:17AM +1000, Damian Conway wrote:
> The point being that methods no longer topicalize their invocant.
To update the design docs, A06 currently says:
Methods, submethods, macros, rules, and pointy subs all
bind their first argument to C<$_>; ordinary subs decl
John Siracusa wrote:
(BTW, I'm not sure where those "./" thingies came from, but it's what GMail
showed in your message. I'm assuming it should just be ".")
No. There's now also a unary ./ operator in Perl 6.
Unary . calls a specified method on the current topic.
Unary ./ calls a specified m
Larry wrote:
: Can I write that as:
:
: sub factorial (Int $n:) {
: return 1 when 0;
: return $n * factorial $n;
: }
As it stands right now, no. Ordinary subs do not allow invocants.
Arguably, it'd be more consistent if ordinary subs always topicalized
their first argument. (But
On Fri, Jun 17, 2005 at 02:29:08PM -0500, Rod Adams wrote:
: Don't you mean:
:
:13
:4
:4
:
: ?
Er, yes. Sorry I've been spouting vaguely incoherent spoutings this
week, but I've been up several times every night trying to deal with a
masked bandit that likes to sneak in the cat doo
On 6/17/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 16, 2005 at 05:18:51PM -0400, John Siracusa wrote:
> : Now in Perl 6 I'll want to use fancy named parameters and so on, but I don't
> : want to lose the abilities described above. How would those examples look
> : in "native" Perl 6 c
On 6/17/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 17, 2005 at 03:56:50AM +0800, Autrijus Tang wrote:
> :
> : my $x = 3;
> : my $y = \$x;
> : say $y + 10;
> : $y++;
> : say $y;
> : say $x;
> :
> I suspect people will find that counterintuitive. A more consiste
Larry Wall wrote:
On Fri, Jun 17, 2005 at 03:56:50AM +0800, Autrijus Tang wrote:
:
: my $x = 3;
: my $y = \$x;
: say $y + 10;
: $y++;
: say $y;
: say $x;
:
: Currently in Pugs they print:
:
: 13
: 4
: 3
:
: Is this sane? What is the scalar reference's s
On Fri, Jun 17, 2005 at 03:56:50AM +0800, Autrijus Tang wrote:
:
: my $x = 3;
: my $y = \$x;
: say $y + 10;
: $y++;
: say $y;
: say $x;
:
: Currently in Pugs they print:
:
: 13
: 4
: 3
:
: Is this sane? What is the scalar reference's semantics in face of a
:
On Thu, Jun 16, 2005 at 05:18:51PM -0400, John Siracusa wrote:
: Now in Perl 6 I'll want to use fancy named parameters and so on, but I don't
: want to lose the abilities described above. How would those examples look
: in "native" Perl 6 code? (i.e., Without forcing all methods to have a
: singl
Larry Wall wrote:
Can anyone think of a good reason not to topicalize the first arg
of ordinary subs these days? Other than subtle encouragement toward
use of multis? I suppose it also makes refactoring between subs and
methods more difficult in the case where you're adding an invocant,
though
On Fri, Jun 17, 2005 at 11:56:11AM -0700, Larry Wall wrote:
> On Fri, Jun 17, 2005 at 09:03:57AM -0500, Patrick R. Michaud wrote:
> : Is '::' acting as a sigil here?
>
> Yes.
>
> : rule variable { [ \( \) ]? }
> : rule sigil { <[EMAIL PROTECTED]&]> <[*.:?^=]>? }
>
> r
On Fri, Jun 17, 2005 at 09:03:57AM -0500, Patrick R. Michaud wrote:
: Is '::' acting as a sigil here?
Yes.
: rule variable { [ \( \) ]? }
: rule sigil { <[EMAIL PROTECTED]&]> <[*.:?^=]>? }
rule sigil { [ <[EMAIL PROTECTED]&]> | <'::'> ] <[*.:?^=]>? }
which would,
On Fri, Jun 17, 2005 at 04:41:53AM +0100, Piers Cawley wrote:
: Suppose I have a simple, single argument recursive function:
:
: sub factorial (Int $n) {
: return 1 if $n == 0;
: return $n * factorial $n;
: }
:
: Can I write that as:
:
: sub factorial (Int $n:) {
: return 1 whe
On Thu, Jun 16, 2005 at 10:28:26PM +, Luke Palmer wrote:
: You know, before I read this part of the message, I was thinking
: precisely that. Nullary splat should do it, so that @foo[*] will
: work. Unary splat would of course get our favor if it can be
: interpreted that way, but in cases li
On Fri, Jun 17, 2005 at 09:19:17AM +0200, "TSa (Thomas Sandlaß)" wrote:
: Ohh, does that mean that ::class can be used as a type
: inside the body? E.g.
:
: method template ( FooClass ::foo :)
: {
:my foo $f;
:
:... # use $f
: }
Certainly. It's exactly the same situation as a &func form
On Fri, Jun 17, 2005 at 08:13:55AM +1000, Damian Conway wrote:
> Patrick wrote:
> >method greet(FooClass $class:) { say "Hello!"; }
>
> No. That needs to be:
>
> method greet(FooClass ::class:) { say "Hello!"; }
>
> (as implied by "takes a class as its invocant" in S12).
Okay, I'm a b
Damian Conway wrote:
No. That needs to be:
method greet(FooClass ::class:) { say "Hello!"; }
(as implied by "takes a class as its invocant" in S12).
^
Ohh, does that mean that ::class can be used as a type
inside the body? E.g.
method template ( FooClass ::f
Damian Conway wrote:
Let's assume that op is overloaded for two completely unrelated types
A and B, which are both defining their respective identity elements
but !(A.identval =:= B.identval). How should the &op multi method object
pick the correct one *without* looking at $value's type?
Your
27 matches
Mail list logo
