Still about subroutines...
Michele Dondi
en passant earlier, I have another question "of mine": I know that in the
vast majority of cases this won't be useful in any way, but in the body of
a (possibly anonymous) sub/block, will there be some sort of identifier to
refer to itself? I mean, in such a way to be able create anonymous
recursive functions. In Perl5 it's doable by means of some trickery that
involves an assignment, anyway.
Thinking of it better lexicals will be in package MY, right, so a possibly
not too out of question choice may be MY::_self (with underscore to avoid
unwanted collisions with user stuff). Something like (hopefully):
print sub -> $n {
# Admittedly stupid example!
return $n if $n<=1;
MY::_self($n-1) + MY::_self($n-2);
}.(10);
Michele
--
> I do have backups, just not recent ones.
I think my wife is now pregnant.
She has a supply of birth control pills and she does use them,
just not recently. ;)
- Jim Lisson in alt.windows98, slightly edited
Luke Palmer
> Speaking of subs, and especially recursive ones which have been
> mentioned en passant earlier, I have another question "of mine": I
> know that in the vast majority of cases this won't be useful in any
> way, but in the body of a (possibly anonymous) sub/block, will there
> be some sort of identifier to refer to itself? I mean, in such a way
> to be able create anonymous recursive functions. In Perl5 it's doable
> by means of some trickery that involves an assignment, anyway.
It used to be &_. But that's changing now to be aliased to the slurpy
block if one exists, and to the target sub of a wrapper.
The new alternative is MY.sub. I suppose that could return the current
actual sub, so if you're using a pointy sub you have to say MY.block or
something. But it's one of those two.
> Thinking of it better lexicals will be in package MY, right, so a possibly
> not too out of question choice may be MY::_self (with underscore to avoid
> unwanted collisions with user stuff). Something like (hopefully):
>
> print sub -> $n {
> # Admittedly stupid example!
> return $n if $n<=1;
> MY::_self($n-1) + MY::_self($n-2);
> }.(10);
You have a redundancy there: "sub" and -> both mean the same thing, so
use one or the other. If you use "sub", the argument list has to be
parenthesized.
Luke
Larry Wall
: The new alternative is MY.sub. I suppose that could return the current
: actual sub, so if you're using a pointy sub you have to say MY.block or
: something. But it's one of those two.
Or something resembling them. I'm still pining for sigils on MY values.
Plus the method notation is problematic: people will wonder why
sub ($x) {
MY.sub($x - 1);
}
doesn't work, not realizing that they'd have to say
MY.sub()($x - 1);
So we're probably going to end up with another secondary sigil, since
it's a weird magical metanamespace. I was going to combine with the
$=DATA magical pod stream namespace, but there's a subtle difference
between a file-scoped metavariable that is the same everywhere in
the file and a lexically scoped metavariable that varies everywhere
in the file. So we probably need a different "ssigil". Here are the
candidates, leaving out brackets and already-used ssigils. (And Unicode).
$`line
$~line
$@line
$#line
$&line
$-line
$+line
$\line
$|line
$;line
$'line
$"line
$,line
$?line
$/line
I like $-, $+, and $? the best. Probably should save $- and $+ for something
complimentary, which leaves $?. It's visually distinctive, and recently
came available. :-)
So maybe $?sub is the name of the current sub, while &?sub is a reference
to the current sub. Maybe $?block is the label on the current block, while
&?block is a ref to the closure?
Larry
Jonathan Scott Duff
> I like $-, $+, and $? the best. Probably should save $- and $+ for something
> complimentary, which leaves $?. It's visually distinctive, and recently
> came available. :-)
Speaking of which ... why is it that $?foo and <?foo> became $<<foo>>
and <<foo>> respectively?
And FWIW, I kinda like $& even with the over-done & :-)
-Scott
--
Jonathan Scott Duff
du...@pobox.com
Juerd
> Speaking of which ... why is it that $?foo and <?foo> became $<<foo>>
> and <<foo>> respectively?
perlcheat is one page. I hope that when Perl 6 is around, I can
summarize all uses of << and >> on one page. The second page will be for
the rest of the syntax :)
Juerd
Joseph Ryan
Don't forget to leave a whole page each for * and : too. :)
- Joe
Luke Palmer
> I like $-, $+, and $? the best. Probably should save $- and $+ for something
> complimentary, which leaves $?. It's visually distinctive, and recently
> came available. :-)
Hmm, $& is pretty good, and it's associated with subs mnemonically, just
as $= is associated with lines (but a little more visually in that
case).
I just wonder whether people will get confused between these:
$&sub
&$sub
Though the latter ought to be written:
$sub()
Nowadays.
Luke
Larry Wall
: Larry Wall writes:
: > I like $-, $+, and $? the best. Probably should save $- and $+ for something
: > complimentary, which leaves $?. It's visually distinctive, and recently
: > came available. :-)
:
: Hmm, $& is pretty good, and it's associated with subs mnemonically, just
: as $= is associated with lines (but a little more visually in that
: case).
Except that only one of these variables' meanings is actually
associated with subs. And I kind of like to read the C<?> as "which".
So if we actually make use of our sigils, we get possibilities like this:
$?file Which file am I in?
$?line Which line am I at?
$?package Which package am I in?
@?package Which packages am I in?
$?module Which module am I in?
@?module Which modules am I in?
$?class Which class am I in?
@?class Which classes am I in?
$?role Which role am I in?
@?role Which roles am I in?
$?grammar Which grammar am I in?
@?grammar Which grammars am I in?
&?sub Which sub am I in?
@?sub Which subs am I in?
$?sub Which sub name am I in?
&?block Which block am I in?
@?block Which blocks am I in?
$?block Which block label am I in?
Some of those may be sillier than others. But the fact that these all
contain a C<?> is a good visual indication that they're all potentially
generic in meaning when you use them in a macro. I kinda like that.
: I just wonder whether people will get confused between these:
:
: $&sub
: &$sub
The real killer is &&sub.
Larry
Larry Wall
: On Thu, Sep 16, 2004 at 10:07:29AM -0700, Larry Wall wrote:
: > I like $-, $+, and $? the best. Probably should save $- and $+ for something
: > complimentary, which leaves $?. It's visually distinctive, and recently
: > came available. :-)
:
: Speaking of which ... why is it that $?foo and <?foo> became $<<foo>>
: and <<foo>> respectively?
Mostly because I got tired of seeing too many question marks meaning
too many things in too many rules. And because the original notion
was that the question mark in $?foo indicated a hypothetical variable,
which turned out to be mostly orthogonal to whether a variable was
stored in $0, so the C<?> ended up indicating nothing questionable.
And because it's really kind of bogus to use variable notation
for things that aren't really variables anyway. And because it
worked out to be the same notation for the C<$0«foo»> syntax
and the C<$«foo»> shorthand syntax on the lookup end of things.
And because I didn't want the capturing form of rules to be longer
than the non-capturing form (ignoring the issue of Texas quotes).
And I wanted to make it so that any angle rule could turn into a
capture rule. Even if we allowed C<?> to prefix any other assertion
like C<!>, it's just more visual noise, unlike brackets which kind of
cancel each other out visually and make a nice "pill". So just as []
turn into () to capture into an array, <> turn into «» to capture
into a hash, where we already use «» notation for constant keys.
Plus I figured we might have some other good use for $?foo some day.
Other than that, no good reason, just a gut feeling.
Larry
Richard Proctor
>
> $?file Which file am I in?
> $?line Which line am I at?
> $?package Which package am I in?
> @?package Which packages am I in?
> $?module Which module am I in?
> @?module Which modules am I in?
> $?class Which class am I in?
> @?class Which classes am I in?
> $?role Which role am I in?
> @?role Which roles am I in?
> $?grammar Which grammar am I in?
> @?grammar Which grammars am I in?
> &?sub Which sub am I in?
> @?sub Which subs am I in?
> $?sub Which sub name am I in?
> &?block Which block am I in?
> @?block Which blocks am I in?
> $?block Which block label am I in?
>
> Some of those may be sillier than others. But the fact that these all
> contain a C<?> is a good visual indication that they're all potentially
> generic in meaning when you use them in a macro. I kinda like that.
Maybe there are some more...
$?perl Which version of perl am I in
And relating to the outside world
$?os Which operating system am I operating on
I am sure there could be many more, perhaps many (all?) of the special
variables could become $? variables for consistency.
Richard
--
Personal Ric...@waveney.org http://www.waveney.org
Telecoms Ric...@WaveneyConsulting.com http://www.WaveneyConsulting.com
Web services Ric...@wavwebs.com http://www.wavwebs.com
Independent Telecomms Specialist, ATM expert, Web Analyst & Services
Thomas Seiler
>
> Maybe there are some more...
>
> $?perl Which version of perl am I in
$?parrot Which version of parrot is perl running on
$?parrot_runloop Which runloop is running ?
etc...
>And relating to the outside world
>
> $?os Which operating system am I operating on
$?pid Which process ID
$?pwd Which working directoy
$?uid Which user ID
etc...
I like it.
Will modules be able to add own / override existig "which"-variables ?
example: a module that provides threads, can it somehow add a
$?thread Which tread am I in
And is it possible to use these in macros aswell?
Thomas Seiler
Jonathan Scott Duff
Maybe I'm just being curmudgeonly, but is this really that useful to
have such shortcuts? I presume that there will be alternate ways to
access the same information (like maybe a special hash
(%*WHICH{'package'} and %*WHICH{'file'}) or some other suitable
abstraction (maybe there's an object that represents the program state
that you can query $*PROG.file, $*PROG.line, etc.))
But is it really worth the the secondary sigil?
Larry Wall
: Maybe I'm just being curmudgeonly, but is this really that useful to
: have such shortcuts? I presume that there will be alternate ways to
: access the same information (like maybe a special hash
: (%*WHICH{'package'} and %*WHICH{'file'}) or some other suitable
: abstraction (maybe there's an object that represents the program state
: that you can query $*PROG.file, $*PROG.line, etc.))
Except it's not program state, which rightfully belongs in the *
namespace. It's lexical scope state, which is a compiler state, and
has nothing to do with run time, or the process state. The process in
question might not even exist yet! That's the fundamental distinction
between the * and ? namespaces.
: But is it really worth the the secondary sigil?
I believe so. We used to have __FILE__ and __LINE__, which had all
the problems of not being variables, but all the advantages of being
single tokens that can be substituted in at compile time. I'd like
to fix the one without breaking the other. I don't see any reason
to stuff a bunch of unrelated items into the same hash, other than
avoiding cluttering up a namespace, and the secondary sigil works
for that just as well. But I think cluttering up the user's mind
with a named abstraction is not terribly useful. The "whichness"
of C<?> happens subconsciously, whereas having a named hash forces
people to think, "Now what was that consarned thing called again?"
People want to think, "I want to interpolate the line number here".
They don't want to think, "I want to interpolate the line number
which is a member of this data structure for some strange reason here."
Larry
Larry Wall
: Maybe there are some more...
:
: $?perl Which version of perl am I in
It would be "Which version of Perl am I compiled with?" But $?perlversion
would much clearer. I suppose the same could be said for $?subname.
: And relating to the outside world
:
: $?os Which operating system am I operating on
Again, which OS am I compiled on, or at best, which OS does the compiler
think I'm compiling for, in the case of cross-compilation.
: I am sure there could be many more, perhaps many (all?) of the special
: variables could become $? variables for consistency.
Most of the special variables are process state, not compiler state, and
should live in * instead of ?.
Larry
Larry Wall
: $?parrot Which version of parrot is perl running on
$?parrotversion would be which version of parrot we were compiled on.
$*parrotversion would be which version of parrot we are running on.
: $?parrot_runloop Which runloop is running ?
Dynamically scoped, so $*parrot_runloop.
: $?pid Which process ID
: $?pwd Which working directoy
: $?uid Which user ID
All unknown to the compiler, so all * variables.
: Will modules be able to add own / override existig "which"-variables ?
At compile time, yes.
: example: a module that provides threads, can it somehow add a
:
: $?thread Which tread am I in
That would be $*thread. Current thread is unknown at compile time.
: And is it possible to use these in macros aswell?
Sure. That's part of the motivation.
Larry
Richard Proctor
>
> Again, which OS am I compiled on, or at best, which OS does the compiler
> think I'm compiling for, in the case of cross-compilation.
>
Therefore should:
$?os Be which operating system it is being compiled on
$*os Be which operating system it is being executed on
Some of the other special variables may have a similar dual personality.
Larry Wall
: Therefore should:
:
: $?os Be which operating system it is being compiled on
: $*os Be which operating system it is being executed on
:
: Some of the other special variables may have a similar dual personality.
Presumably. Which presents an interesting problem, because we
currently have things defined like $*PID, not $*pid. Either we
have to lowercase the $* variables, or uppercase the $? variables,
or decide that it's okay for them to be different. It's probably
important to keep $*PID uppercase because of the way they can leak into
any other namespace as $PID. The same does not hold true for $?line.
On the other hand, people are used to __LINE__ already, so maybe $?LINE
isn't so bad, and lights up better as a weird unit with a rectangular
shape, something you might see as a funny symbol in a macro assembler.
Which is more or less what it is.
I originally made them lowercase because they were $=line variables
and I didn't want them to conflict with POD names that are typically
uppercase, and use of an C<=> secondary sigil for POD is a no-brainer.
But that no longer applies when they have their own ssigil, or sigil2,
or 2igil. I guess that would be pronounce "twidgle".
Larry
Austin Hastings
For that matter, what's wrong with $__ as a sigil, as in $__LINE__, et
al. It combines the "you can use it as a variable" with the "leading
underscores are magic" memes, and doesn't impose any wierd learning curve.
=Austin
>Larry
>
>
>
David Wheeler
> I originally made them lowercase because they were $=line variables
> and I didn't want them to conflict with POD names that are typically
> uppercase, and use of an C<=> secondary sigil for POD is a no-brainer.
s/uppercase/lowercase/ ?
David
Larry Wall
: For that matter, what's wrong with $__ as a sigil, as in $__LINE__, et
: underscores are magic" memes, and doesn't impose any wierd learning curve.
I am unlikely to buy any use of _ as a twigil because it conflicts
with user variable space.
Larry
Larry Wall
No, not the verbs, the uppercase nouns we see like
=begin COMMENT
...
=end COMMENT
Larry
David Wheeler
> No, not the verbs, the uppercase nouns we see like
>
> =begin COMMENT
> ...
> =end COMMENT
Oh, I wasn't sure, because in the Synopses you've been using propercase
for =head1 POD. But maybe it's not the subjects of the header and item
type verbs you're concerned with...
Thanks,
David
Michele Dondi
> And FWIW, I kinda like $& even with the over-done & :-)
me too!
Michele
--
> [...] is like requiring to play tennis with a square ball.
Which admittedly makes the game more interesting.
- Giuseppe "Oblomov" Bilotta in comp.text.tex (edited)
Michele Dondi
> Except that only one of these variables' meanings is actually
> associated with subs. And I kind of like to read the C<?> as "which".
> So if we actually make use of our sigils, we get possibilities like this:
[snip useful examples]
at first I didn't get what you mean, but now I must admit it does make
sense and looks smart too.
Michele
--
Yesterday I was in doubt whether to add you to my killfile.
Today, I no longer have that doubt.
- Alan J. Flavell in clpmisc, "Re: short script differences"
Michele Dondi
> with a named abstraction is not terribly useful. The "whichness"
> of C<?> happens subconsciously, whereas having a named hash forces
As I said in my other mail, the more I think of this the more it seems to
me to be reasonable and even "natural". It's "which?-ness", though! ;-)
Michele
--
>I hold a square measuring 10x10 metres away from a person who is standing
>100 metres away.
>I ask them to shoot the square with a high-accuracy gun.
Don't stand there holding the square when they are shooting...
- Robert Israel in sci.math, "Re: Scaling"
Larry Wall
: at first I didn't get what you mean, but now I must admit it does make
I can be very persuasive when I'm right, as well as the rest of the time. :-)
Larry