FAQ
https://rt.perl.org/rt3//Ticket/Display.html?id=80628

This thread became quiet because 5.13 went into a holding pattern before 5.14.
I would like, so help me, to bring it up again.

In brief, I like the idea of __SUB__ and I think that it is a completely
reasonable name for the thing. Objections that existed at the time included:

## __SUB__ looks like other __THING__s, many of which are compile-time
## constants, but __SUB__ would not be

I think Abigail thoroughly defused this argument, and refer readers to the bug.
I think __SUB__ is an excellent name for it.

## this should be (and is) on CPAN; therefore, it need not be in core

I agree that it need not be in core, but I think it *ought* to be in core. It
is not a complex feature, but is quite useful. More importantly, it isn't
very opinionated. It provides a simple facility in about the simplest way it
could be provided. I believe this feature will improve Perl 5, and I have a
hard time envisioning a future where we lament its addition.

## this should be a module, not a core language feature

First, I don't think a programmer should have to say "use Sub::Current;" to get
this feature. I don't see that cost as being justified.

Should the implementation of __SUB__ live in an external module? Maybe! What
if we were to core Sub::Current, convince its author to provide a __SUB__
export (identical to current_sub) and then add the import of this to the :5.16
feature bundle, for example?

I'm not terribly bothered about whether the implementation belongs in a module
or the core language. My instinct would be the language, but I'm interested in
hearing from the people who are talking about doing the actual work!

----

I would like to land this feature in 5.16 if we can come to a general
consensus. If you think this is a mistake, please convince me.

--
rjbs

Search Discussions

  • Rafael Garcia-Suarez at Nov 11, 2011 at 8:27 am

    On 11 November 2011 00:37, Ricardo Signes wrote:
    ##  this should be a module, not a core language feature

    First, I don't think a programmer should have to say "use Sub::Current;" to get
    this feature.  I don't see that cost as being justified.

    Should the implementation of __SUB__ live in an external module?  Maybe!  What
    if we were to core Sub::Current, convince its author to provide a __SUB__
    export (identical to current_sub) and then add the import of this to the :5.16
    feature bundle, for example?
    I can do that if that's you wish. Note that Sub::Current currently
    exports ROUTINE(), not current_sub(). We can also put magic loading ÃÂ
    la %! (loading Errno when parsed), but ugh. Just mentioning that for the
    sake of completeness.

    (Oh, I notice that I did not even put Sub::Current on github. Will
    fix.)

    --
    Every old idea will be proposed again with a different name and a different
    presentation, regardless of whether it works.
    -- RFC 1925
  • Zefram at Nov 11, 2011 at 11:14 am
    I remain of the opinion that the __SUB__ functionality should remain on
    CPAN, requiring an explicit importation. If we were to make it available
    by default in the CORE:: namespace merely on the grounds that it's quite
    useful, we'd have to make hundreds of other things available there in
    the same way. It's the same problem we historically had with inflation
    of the set of modules included in the core distro, which we're only now
    recovering from by kicking them out to CPAN. But the CORE:: form of
    the problem is more difficult to recover from, because the feature is
    available without even an explicit module load.

    We need stronger reasons if it is to go into CORE:: (or even if the
    module is to be dual-lifed). We could start by hearing from people who
    actually use it in production, or who would like to use it in production
    but are somehow hindered by it not being in CORE::.

    -zefram
  • Rafael Garcia-Suarez at Nov 11, 2011 at 11:22 am

    On 11 November 2011 12:14, Zefram wrote:
    I remain of the opinion that the __SUB__ functionality should remain on
    CPAN, requiring an explicit importation.  If we were to make it available
    by default in the CORE:: namespace merely on the grounds that it's quite
    useful, we'd have to make hundreds of other things available there in
    the same way.  It's the same problem we historically had with inflation
    of the set of modules included in the core distro, which we're only now
    recovering from by kicking them out to CPAN.  But the CORE:: form of
    the problem is more difficult to recover from, because the feature is
    available without even an explicit module load.
    I agree; I see more useful things (to me) to import implicitely to
    CORE:: (like, lift() :) and I would not even push them for inclusion
    in the core.
  • David Golden at Nov 11, 2011 at 12:12 pm

    On Fri, Nov 11, 2011 at 6:14 AM, Zefram wrote:
    We need stronger reasons if it is to go into CORE:: (or even if the
    module is to be dual-lifed).
    Without reference to __SUB__ specifically, one potential reason for a
    highly useful feature to go into core would be if it is implemented in
    XS.

    Since not all Perl installations have compilers available, some
    internals-mangling/inspecting features might be appropriate for
    inclusion directly in core.

    -- David
  • Nicholas Clark at Nov 11, 2011 at 12:21 pm

    On Fri, Nov 11, 2011 at 07:11:40AM -0500, David Golden wrote:
    On Fri, Nov 11, 2011 at 6:14 AM, Zefram wrote:
    We need stronger reasons if it is to go into CORE:: (or even if the
    module is to be dual-lifed).
    Without reference to __SUB__ specifically, one potential reason for a
    highly useful feature to go into core would be if it is implemented in
    XS.

    Since not all Perl installations have compilers available, some
    internals-mangling/inspecting features might be appropriate for
    inclusion directly in core.
    But is the functionality of __SUB__ something that would naturally be
    provided by a meta-model?


    The "no XS" is a valid problem. The current solution to it seems to be
    add features and modules to address specific deficiencies as they are
    identified. The results are inconsistent at best, not always optimal*,
    and certainly not coherent.

    If it is something that falls out naturally from a meta model, given that
    there is work to implement such a beast, isn't it better to provide it as
    part of that? (And revisit the idea of a dedicated keyword if the meta
    model work fails.)

    Nicholas Clark

    * Assimilating the "best of breed" CPAN module for a given task may not be
    optimal, as CPAN modules are limited in what syntax they use, and what
    hooks exist at XS level. They may have been prevented from implementing
    an optimal solution because that would have needed core changes.
  • Stevan Little at Nov 11, 2011 at 6:57 pm

    On Nov 11, 2011, at 12:21 PM, Nicholas Clark wrote:
    On Fri, Nov 11, 2011 at 07:11:40AM -0500, David Golden wrote:
    On Fri, Nov 11, 2011 at 6:14 AM, Zefram wrote:
    We need stronger reasons if it is to go into CORE:: (or even if the
    module is to be dual-lifed).
    Without reference to __SUB__ specifically, one potential reason for a
    highly useful feature to go into core would be if it is implemented in
    XS.

    Since not all Perl installations have compilers available, some
    internals-mangling/inspecting features might be appropriate for
    inclusion directly in core.
    But is the functionality of __SUB__ something that would naturally be
    provided by a meta-model?
    Well, not really, the meta-model will not care about subs, it only cares about methods. We can certainly add it for methods, but I am not sure it would be useful for methods as it would be for subs (assuming the primary use for this is recursion, which is what I always used Sub::Current for).

    - Stevan
  • Aristotle Pagaltzis at Nov 11, 2011 at 5:17 pm

    * Zefram [2011-11-11 12:15]:
    If we were to make it available by default in the CORE:: namespace
    merely on the grounds that it's quite useful, we'd have to make
    hundreds of other things available there in the same way.
    Why?
  • Zefram at Nov 11, 2011 at 5:20 pm

    Aristotle Pagaltzis wrote:
    Why?
    Because there are many other things in modules that are similarly useful
    and which would be possible to put in the core. If we put this one in
    then a bad precedent will be set.

    -zefram
  • David Golden at Nov 11, 2011 at 5:34 pm

    On Fri, Nov 11, 2011 at 12:19 PM, Zefram wrote:
    Aristotle Pagaltzis wrote:
    Why?
    Because there are many other things in modules that are similarly useful
    and which would be possible to put in the core.  If we put this one in
    then a bad precedent will be set.
    It's only a bad precedent if the grounds for inclusion are poorly
    specified or poorly understood.

    If grounds for inclusion are well specified and well understood, then
    anything which passes the test rightfully *should* be included.

    I'd rather see more energy trying to clarify what we think are grounds
    for inclusion than debating any given module.

    And to run that thought exercise in reverse, anything *currently* in
    core that fails the grounds could become a candidate for
    modularization and future deprecation.

    -- David
  • Nicholas Clark at Nov 11, 2011 at 6:04 pm

    On Fri, Nov 11, 2011 at 12:34:05PM -0500, David Golden wrote:
    On Fri, Nov 11, 2011 at 12:19 PM, Zefram wrote:
    Aristotle Pagaltzis wrote:
    Why?
    Because there are many other things in modules that are similarly useful
    and which would be possible to put in the core.  If we put this one in
    then a bad precedent will be set.
    It's only a bad precedent if the grounds for inclusion are poorly
    specified or poorly understood.
    The grounds for inclusion on many many things seem to be a variant of

    "I find this very useful and it is something that is in my core toolkit"

    in some cases its also "PHP has this big advantage over Perl on low end
    hosting because it comes with X by default; without X we can't do Y"

    [for some value of PHP. And I'm not *dismissing* that argument - I've
    already said in a previous e-mail that it's valid, as long term, Perl
    needs to suck new people in, and anything that makes it harder to
    persuade people to try Perl is a hinderance. This makes it harder]


    But we've fundamentally *not* solved the problem of the Perl 6 RFC process
    back 10 years ago - 361 proposals, most of which were "Perl 5 is great, apart
    from these 1 or 2 deficiencies that I'd like to see addressed":

    http://dev.perl.org/perl6/rfc/

    most of which were raising valid problems
    many of which offered solutions valid in isolation
    but adopt all, and it's a complete mess.

    We are still doing this today, when we add things. Not realising the corner
    cases, or how things combine.


    It's also the case that an argument for X is that X is the only XS
    prerequisite that common task Y needs. This is valid. However, the
    state of the art changes, and so what people are trying to do changes,
    [this is natural, and not unexpected] so it seems to be steady state
    that there's always just "one more thing" that would be useful.

    Currently most concerns seem to be about meta models, highlighted by what
    Moose needs.

    However, we have never stopped to address this *coherently*. We certainly
    don't have a Guido, someone with a firm view of what's "Pythonic", what's
    possible, and what is progress.

    (Change is inevitable, progress is not. Hence, one should attempt to
    maximise progress as a function of change.)
    If grounds for inclusion are well specified and well understood, then
    anything which passes the test rightfully *should* be included.

    I'd rather see more energy trying to clarify what we think are grounds
    for inclusion than debating any given module.

    And to run that thought exercise in reverse, anything *currently* in
    core that fails the grounds could become a candidate for
    modularization and future deprecation.
    The trouble, consistently, has been that everyone is prepared to *talk*
    an awful lot about why X should stay, but not to pledge the same effort
    into maintaining it long term, let alone follow through on a pledge.

    Nicholas Clark
  • Aristotle Pagaltzis at Nov 11, 2011 at 6:10 pm

    * Nicholas Clark [2011-11-11 19:05]:
    But we've fundamentally *not* solved the problem of the Perl 6 RFC
    process back 10 years ago - 361 proposals, most of which were "Perl
    5 is great, apart from these 1 or 2 deficiencies that I'd like to see
    addressed":

    http://dev.perl.org/perl6/rfc/

    most of which were raising valid problems
    many of which offered solutions valid in isolation
    but adopt all, and it's a complete mess.

    We are still doing this today, when we add things. Not realising the
    corner cases, or how things combine.
    Yesssssssssssssssssss.

    Thank you.
    However, we have never stopped to address this *coherently*. We
    certainly don't have a Guido, someone with a firm view of what's
    "Pythonic", what's possible, and what is progress.
    And odd sole choice of person to mention. :-)

    I miss Larry. :-(

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Nicholas Clark at Nov 11, 2011 at 8:48 pm

    On Fri, Nov 11, 2011 at 07:10:45PM +0100, Aristotle Pagaltzis wrote:
    * Nicholas Clark [2011-11-11 19:05]:
    But we've fundamentally *not* solved the problem of the Perl 6 RFC
    process back 10 years ago - 361 proposals, most of which were "Perl
    5 is great, apart from these 1 or 2 deficiencies that I'd like to see
    addressed":
    However, we have never stopped to address this *coherently*. We
    certainly don't have a Guido, someone with a firm view of what's
    "Pythonic", what's possible, and what is progress.
    And odd sole choice of person to mention. :-)
    In particular, http://bugs.python.org/issue1298 was on my mind.

    Title: Support for z/OS and EBCDIC.

    final response, from Guido, starts

    I have no desire or time to continue this discussion.

    He's rather blunt in his rejections. Python (or at least, Guido) is also
    more willing to break things than Perl.

    (This is both a strength and a weakness)

    Combine this with Python's rejection of "more than one way to do it", and
    to me as an outsider, it feels like it's more important to determine how
    "pythonic" something is, as it's more necessary to have the way to do it
    be right, as it would be heretical to later find a better way of doing it,
    simply because it would more than one way.
    I miss Larry. :-(
    So do I. Certainly, I miss having someone thinking about how it fits
    together, and where it should be headed.

    However, there are some things you can't fix in Perl 5 (the language)
    without breaking backwards compatibility. There are some things you can't
    fix in perl 5 (the implementation)*

    I hope I'm not misrepresenting what happened by interpreting it as
    Larry decided that it was more fruitful long term to solve the problems
    properly, instead of being forced to live within the constraints of the
    unfixable parts.

    Nicholas Clark

    * Specifically, it really hurts that at the XS level, it's direct structure
    access, instead of function calls via vtables. It really hurts that some
    mutatation is done by getting a pointer to a buffer, and then writing
    direct to it. ie there's no call to say "I'm finished". Which means that
    the internal representation has to remain the same, as it's exposed.
    You can't even hook in to tidy up the buffer after they're done.
  • Abigail at Nov 14, 2011 at 12:17 pm

    On Fri, Nov 11, 2011 at 07:10:45PM +0100, Aristotle Pagaltzis wrote:

    I miss Larry. :-(

    I don't.

    That's nothing personal to Larry. But we do have a pumpking. And IMO,
    one of the roles of a pumpking should be to "be Larry" when it comes
    to language decisions. And we certainly shouldn't be waving "We don't
    have a Larry" -- that undermines the position of the role of the pumpking.



    Abigail
  • Aristotle Pagaltzis at Nov 14, 2011 at 3:50 pm

    * Abigail [2011-11-14 13:20]:
    On Fri, Nov 11, 2011 at 07:10:45PM +0100, Aristotle Pagaltzis wrote:
    I miss Larry. :-(
    I don't.

    That's nothing personal to Larry. But we do have a pumpking. And IMO,
    one of the roles of a pumpking should be to "be Larry" when it comes
    to language decisions.
    If you mean this in the sense that I mean that I miss Larry, then that
    is a huge and probably impossible demand on the pumpking. Are you aware
    of how much you are asking for here?
    And we certainly shouldn't be waving "We don't have a Larry" -- that
    undermines the position of the role of the pumpking.
    Only if you think they actually can “be Larry” in the first place, other
    than in one of some number of very narrow senses.

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Ricardo Signes at Nov 11, 2011 at 6:38 pm
    * David Golden [2011-11-11T12:34:05]
    If grounds for inclusion are well specified and well understood, then
    anything which passes the test rightfully *should* be included.
    I don't want a language designed by an algorithm.

    --
    rjbs
  • David Golden at Nov 11, 2011 at 7:19 pm

    On Fri, Nov 11, 2011 at 1:38 PM, Ricardo Signes wrote:
    * David Golden [2011-11-11T12:34:05]
    If grounds for inclusion are well specified and well understood, then
    anything which passes the test rightfully *should* be included.
    I don't want a language designed by an algorithm.
    I want a language that is designed, not accreted.

    Design means choice. Choice means tradeoffs. Tradeoffs need criteria.

    Whether those criteria are formal or not, whether they live in the
    mind of a supreme leader or not, is yet another choice.

    I offer the point of view that we'd all spend less time arguing in
    circles, bikeshedding or warnocking if we spent more time on criteria
    and less time on cases when criteria are poorly established.

    -- David
  • Nicholas Clark at Nov 11, 2011 at 8:01 pm

    On Fri, Nov 11, 2011 at 02:18:58PM -0500, David Golden wrote:
    On Fri, Nov 11, 2011 at 1:38 PM, Ricardo Signes
    wrote:
    * David Golden [2011-11-11T12:34:05]
    If grounds for inclusion are well specified and well understood, then
    anything which passes the test rightfully *should* be included.
    I don't want a language designed by an algorithm.
    I want a language that is designed, not accreted.
    I don't think that anyone is going to disagree with that.
    But I think that it's useful to remind ourselves of that.
    Design means choice. Choice means tradeoffs. Tradeoffs need criteria.

    Whether those criteria are formal or not, whether they live in the
    mind of a supreme leader or not, is yet another choice.

    I offer the point of view that we'd all spend less time arguing in
    circles, bikeshedding or warnocking if we spent more time on criteria
    and less time on cases when criteria are poorly established.
    I fear that we'd spend an awful lot of time arguing about criteria
    (round in circles), if we try to argue them in the abstract.

    I think that way to go forwards (and avoid circles, or at least convert them
    to spirals), is to do both in parallel - iterate the criteria based on what
    they accept/reject, and allow the criteria a rule 2 ("can change [its] mind")


    I'm also still wary of the 5.6.0 and earlier messes we (for a small value of
    we) are still working to clear up, including but not limited to

    * v strings that weren't objects
    * Unicode exposed as UTF-8; SvPV() implicitly changing meaning
    * "experimental" features in the regex engine
    * lvalue subroutines


    The complexity of the VM makes it too easy to add something that has
    ramifications for a decade to come.

    Nicholas Clark
  • Ricardo Signes at Nov 11, 2011 at 10:07 pm
    * Nicholas Clark [2011-11-11T15:00:54]
    On Fri, Nov 11, 2011 at 02:18:58PM -0500, David Golden wrote:

    I offer the point of view that we'd all spend less time arguing in
    circles, bikeshedding or warnocking if we spent more time on criteria
    and less time on cases when criteria are poorly established.
    I fear that we'd spend an awful lot of time arguing about criteria
    (round in circles), if we try to argue them in the abstract.
    Certainly apparently-clear criteria have not helped Wikipedia avoid arguing in
    circles, bikeshedding, or worse.

    --
    rjbs
  • Aristotle Pagaltzis at Nov 11, 2011 at 10:57 pm

    * Ricardo Signes [2011-11-11 23:10]:
    * Nicholas Clark [2011-11-11T15:00:54]
    On Fri, Nov 11, 2011 at 02:18:58PM -0500, David Golden wrote:
    I offer the point of view that we'd all spend less time arguing in
    circles, bikeshedding or warnocking if we spent more time on
    criteria and less time on cases when criteria are poorly
    established.
    I fear that we'd spend an awful lot of time arguing about criteria
    (round in circles), if we try to argue them in the abstract.
    Certainly apparently-clear criteria have not helped Wikipedia avoid
    arguing in circles, bikeshedding, or worse.
    Yes. Deferring everything to rules doesn’t lead to less discussion, it
    leads to more: about whether any given rule applies, about exactly how
    it applies, about which of several applicable rules takes precedent and
    why, about whether a rule should be changed or not.

    To try to formalise everything is to try to turn everyone into lawyers.

    When what you wanted are artisans.

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • David Golden at Nov 12, 2011 at 1:21 am

    On Fri, Nov 11, 2011 at 5:57 PM, Aristotle Pagaltzis wrote:
    Certainly apparently-clear criteria have not helped Wikipedia avoid
    arguing in circles, bikeshedding, or worse.
    No, it hasn't. Possibly because of the inherently malleable nature of
    a wiki. The cost of change is minimal, so the urge to do it is
    greater.
    Yes. Deferring everything to rules doesn’t lead to less discussion, it
    leads to more: about whether any given rule applies, about exactly how
    it applies, about which of several applicable rules takes precedent and
    why, about whether a rule should be changed or not.
    I think that is a much more substantive debate than arguing every
    individual case again from scratch, and that over time, there will be
    fewer such arguments.
    To try to formalise everything is to try to turn everyone into lawyers.
    Formalizing nothing leads to chaos. We've already formalized things
    beyond Rules 1 & 2 and I think that's progress.

    For example, I believe that perlpolicy has been a step forward
    precisely because it clarifies maintenance criteria so that not every
    decision has to go to the pumpkin for resolution. For example
    "Patches that add new warnings or errors or deprecate features are not
    acceptable" -- it's very specific and very clear. A patch either does
    or does not do such things. There's no debate over whether a patch is
    "useful enough" or "urgent" or whether the benefit is worth the cost.
    The policy says no. And non-pumpkings can judge a patch against that
    criteria and act accordingly.

    I'll make my point differently: when people on p5p argue over a point,
    I believe they often do so because of different -- often unstated --
    assumptions, contexts or criteria for what's important to them
    individually. I believe that getting beneath the surface arguments
    about feature X or change Y to the underlying differences will lead to
    more constructive discussions.

    I think we're better off when we ask people "why do you believe what
    you believe" and "what would have to change for you to feel the other
    way"?

    None of that necessarily means "rules" or "algorithms" for decisions.
    It does mean having design discussions at something deeper than a
    surface level.

    -- David
  • Ricardo Signes at Nov 12, 2011 at 1:46 am
    * David Golden [2011-11-11T20:20:35]
    I think we're better off when we ask people "why do you believe what
    you believe" and "what would have to change for you to feel the other
    way"?
    I can get behind that in a big way.

    --
    rjbs
  • Aristotle Pagaltzis at Nov 11, 2011 at 6:04 pm

    * Zefram [2011-11-11 18:25]:
    Because there are many other things in modules that are similarly
    useful and which would be possible to put in the core. If we put this
    one in then a bad precedent will be set.
    Why?

    :-)

    This is a slippery slope argument.

    But language design is not an exact science.

    Just because one thing is added for a particular reason does not mean
    everything to which that reason applies also has to be added. From the
    perspective of objective criteria, a certain kind of capriciousness is
    good. It is what, from that angle, taste means.



    Now to come back to the point here:

    The existing ways to achieve the purpose of __SUB__ are annoying, but
    easy enough that one wouldn’t even think to look for a module – I know
    I wouldn’t. And even if they know about it, installing a module from
    CPAN for it is simply not worth the trouble – I know I wouldn’t.

    In practice therefore it comes down to a form of Hobson’s choice: either
    it’s in core or no one uses it. So the question is: can we tell what the
    cost of putting it in core is? And if so, is it worth the price?

    It appears well-defined and self-contained semantically, apparently free
    of interactions with other parts of the language. And it is so tiny in
    terms of implementation that it would incur negligible long-term cost of
    maintenance in core.

    So though seemingly there are more options, the question boils down: do
    we prefer to make people continue to do it the tedious way or do we want
    to offer them a convenience? Would it fit the language?

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Michael G Schwern at Nov 12, 2011 at 9:44 pm

    On 2011.11.10 3:37 PM, Ricardo Signes wrote:
    In brief, I like the idea of __SUB__ and I think that it is a completely
    reasonable name for the thing.
    My only reasonable objection is that __THING__ is awkward to type and can't be
    interpolated. This is why I wrote CLASS to provide $CLASS.
    http://search.cpan.org/perldoc?CLASS

    For that reason I'd prefer $^SUB, it's easier to type and more useful. I
    agree that it should be visually similar to __PACKAGE__, __FILE__ and
    __LINE__, so I'd rather $^PACKAGE, $^FILE and $^LINE were added. This brings
    the utility and ease of a whole class of features UP rather than dragging
    every new one added DOWN.

    While I agree that $^FOO hints that it may be assigned, read-only scalars are
    not some crazy thing and the user will get a very sharp and clear error.
    $^FILE = 'foo'; $^LINE = 42; could even supersede the hacky "# file line"
    not-comment. They're not even read only!


    --
    31. Not allowed to let sock puppets take responsibility for any of my
    actions.
    -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
    http://skippyslist.com/list/
  • John Imrie at Nov 12, 2011 at 11:47 pm

    On 12/11/2011 21:44, Michael G Schwern wrote:
    On 2011.11.10 3:37 PM, Ricardo Signes wrote:
    In brief, I like the idea of __SUB__ and I think that it is a completely
    reasonable name for the thing.
    My only reasonable objection is that __THING__ is awkward to type and can't be
    interpolated. This is why I wrote CLASS to provide $CLASS.
    http://search.cpan.org/perldoc?CLASS

    For that reason I'd prefer $^SUB, it's easier to type and more useful. I
    agree that it should be visually similar to __PACKAGE__, __FILE__ and
    __LINE__, so I'd rather $^PACKAGE, $^FILE and $^LINE were added. This brings
    the utility and ease of a whole class of features UP rather than dragging
    every new one added DOWN.

    While I agree that $^FOO hints that it may be assigned, read-only scalars are
    not some crazy thing and the user will get a very sharp and clear error.
    $^FILE = 'foo'; $^LINE = 42; could even supersede the hacky "# file line"
    not-comment. They're not even read only!
    I like this idea if we can make it work, especially being able to assign
    to them.

    $^SUB = 'package::new_sub_name'; becomes a clean way of assigning names
    to anonymous subs. Not sure what to do if the sub is not anonymous,
    $^PACKAGE = 'package_name'; equates to package package_name.
    $^LINE= 10; equates to # line 10
    $^FILE = 'my_file_name'; is # file my_file_name

    Which means we can do things like

    my @quarks;
    foreach my $quark (qw(up down charm strange top bottom)) {
    push @quarks, get_quark($quark);
    }

    sub get_quark {
    my $quark = shift;
    return sub {
    $^SUB = "get_$quark";
    return heisenberg(////$quark);
    };
    }

    print get_up;

    This means that assigning to $^SUB has to store a reference to the
    current sub in the current package's stash. Except that the assignment
    to $^SUB only gets called when get_up is called by which time it's too late.

    So I guess I'm saying I'm not sure how assigning to $^SUB would work.

    John
  • David Golden at Nov 13, 2011 at 12:51 am

    On Sat, Nov 12, 2011 at 4:44 PM, Michael G Schwern wrote:
    For that reason I'd prefer $^SUB, it's easier to type and more useful.  I
    agree that it should be visually similar to __PACKAGE__, __FILE__ and
    __LINE__, so I'd rather $^PACKAGE, $^FILE and $^LINE were added.  This brings
    the utility and ease of a whole class of features UP rather than dragging
    every new one added DOWN.
    +1

    -- David
  • Stevan Little at Nov 13, 2011 at 1:00 am

    On Nov 13, 2011, at 12:51 AM, David Golden wrote:
    On Sat, Nov 12, 2011 at 4:44 PM, Michael G Schwern wrote:
    For that reason I'd prefer $^SUB, it's easier to type and more useful. I
    agree that it should be visually similar to __PACKAGE__, __FILE__ and
    __LINE__, so I'd rather $^PACKAGE, $^FILE and $^LINE were added. This brings
    the utility and ease of a whole class of features UP rather than dragging
    every new one added DOWN.
    +1
    +1

    I would love to have $^CLASS for the p5-mop as well.

    - Stevan
  • Ricardo Signes at Nov 13, 2011 at 12:59 am
    * Michael G Schwern [2011-11-12T16:44:29]
    For that reason I'd prefer $^SUB, it's easier to type and more useful. I
    agree that it should be visually similar to __PACKAGE__, __FILE__ and
    __LINE__, so I'd rather $^PACKAGE, $^FILE and $^LINE were added. This brings
    the utility and ease of a whole class of features UP rather than dragging
    every new one added DOWN.
    Saying nothing about the rest of the __THING__s mentioned, what's more useful
    about interpolating a coderef?


    --
    rjbs
  • Michael G Schwern at Nov 13, 2011 at 8:45 pm

    On 2011.11.12 4:59 PM, Ricardo Signes wrote:
    * Michael G Schwern [2011-11-12T16:44:29]
    For that reason I'd prefer $^SUB, it's easier to type and more useful. I
    agree that it should be visually similar to __PACKAGE__, __FILE__ and
    __LINE__, so I'd rather $^PACKAGE, $^FILE and $^LINE were added. This brings
    the utility and ease of a whole class of features UP rather than dragging
    every new one added DOWN.
    Saying nothing about the rest of the __THING__s mentioned, what's more useful
    about interpolating a coderef?
    Oh, I misunderstood. I thought __SUB__ would contain the name the current
    subroutine was called as. So to answer your question: nothing.

    I'm a little late to the party... the original bug justifies __SUB__ to avoid
    circular references in self-referencing closures. It seems a long way to go
    for a fairly obscure issue... but I don't see the harm if it's not too invasive.

    Does it solve any other problem?


    --
    package Outer::Space; use Test::More tests => 9;
  • Dave Mitchell at Nov 14, 2011 at 11:07 am

    On Sat, Nov 12, 2011 at 01:44:29PM -0800, Michael G Schwern wrote:
    While I agree that $^FOO hints that it may be assigned, read-only scalars are
    not some crazy thing and the user will get a very sharp and clear error.
    $^FILE = 'foo'; $^LINE = 42; could even supersede the hacky "# file line"
    not-comment. They're not even read only!
    Except that '#file line' is compile-time.

    --
    Lady Nancy Astor: If you were my husband, I would flavour your coffee
    with poison.
    Churchill: Madam - if I were your husband, I would drink it.
  • Michael G Schwern at Nov 15, 2011 at 12:31 am

    On 2011.11.14 3:07 AM, Dave Mitchell wrote:
    On Sat, Nov 12, 2011 at 01:44:29PM -0800, Michael G Schwern wrote:
    While I agree that $^FOO hints that it may be assigned, read-only scalars are
    not some crazy thing and the user will get a very sharp and clear error.
    $^FILE = 'foo'; $^LINE = 42; could even supersede the hacky "# file line"
    not-comment. They're not even read only!
    Except that '#file line' is compile-time.
    Good point.

    Does it have to be?

    Obviously if you want it to have effect at compile-time, then yes. But I
    mostly use it for run-time effect to change the output of die or warn.
    Usually to make it fixed for testing.

    What are the compile-time uses?
    Is the implementation inexorably tied to being done at compile-time?

    PS I realize I'm building a whole other bike shed here. I'll take this
    examination of $^FILE and $^LINE into its own thread.


    --
    52. Not allowed to yell "Take that Cobra" at the rifle range.
    -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
    http://skippyslist.com/list/
  • Rafael Garcia-Suarez at Nov 15, 2011 at 6:36 am

    On 15 November 2011 01:31, Michael G Schwern wrote:
    On 2011.11.14 3:07 AM, Dave Mitchell wrote:
    On Sat, Nov 12, 2011 at 01:44:29PM -0800, Michael G Schwern wrote:
    While I agree that $^FOO hints that it may be assigned, read-only scalars are
    not some crazy thing and the user will get a very sharp and clear error.
    $^FILE = 'foo'; $^LINE = 42; could even supersede the hacky "# file line"
    not-comment.  They're not even read only!
    Except that '#file line' is compile-time.
    Good point.

    Does it have to be?

    Obviously if you want it to have effect at compile-time, then yes.  But I
    mostly use it for run-time effect to change the output of die or warn.
    Usually to make it fixed for testing.

    What are the compile-time uses?
    Is the implementation inexorably tied to being done at compile-time?
    I think so : file and line are stored in the optree (or nearby), which
    doesn't change after compilation.
  • Father Chrysostomos at Nov 20, 2011 at 10:37 pm

    Michael Schwern wrote:
    Oh, I misunderstood. I thought __SUB__ would contain the name the current
    subroutine was called as. So to answer your question: nothing.

    I'm a little late to the party... the original bug justifies __SUB__ to avoid
    circular references in self-referencing closures. It seems a long way to go
    for a fairly obscure issue... but I don't see the harm if it's not too invasive.

    Does it solve any other problem?
    On its own, no; but it’s a single piece in a larger puzzle.
    Introducing lexical subs without this would be embarrassing. The only way to get recursion would be the laughable:

    my sub foo;
    my sub foo {
    ...
    foo();
    ...
    }

    Pretty soon you’ll see the repetition become a ‘best practice’. Using __SUB__->() inside the sub is an elegant solution. (And please, please, let’s not introduce a new set of scoping rules instead.)

    Package and subroutine syntax have been converging. If we continue that trend, then Perl syntax will be conceptually simpler as a whole.

    If we introduce anonymous packages via package {...} syntax, then __PACKAGE__ will have to return a reference to the anonymous package. __SUB__ would be appropriate in that case for completeness’ sake.
  • Jesse Luehrs at Nov 20, 2011 at 10:51 pm

    On Sun, Nov 20, 2011 at 02:36:57PM -0800, Father Chrysostomos wrote:
    Michael Schwern wrote:
    Oh, I misunderstood. I thought __SUB__ would contain the name the
    current subroutine was called as. So to answer your question:
    nothing.

    I'm a little late to the party... the original bug justifies __SUB__
    to avoid circular references in self-referencing closures. It seems
    a long way to go for a fairly obscure issue... but I don't see the
    harm if it's not too invasive.

    Does it solve any other problem?
    On its own, no; but it’s a single piece in a larger puzzle.
    Introducing lexical subs without this would be embarrassing. The only
    way to get recursion would be the laughable:

    my sub foo; my sub foo { ... foo(); ... }

    Pretty soon you’ll see the repetition become a ‘best practice’. Using
    __SUB__->() inside the sub is an elegant solution. (And please,
    please, let’s not introduce a new set of scoping rules instead.)
    For what it's worth, "a new set of scoping rules" is how other languages
    handle the issue - for instance, 'let' vs 'let rec' in OCaml. I've never
    had an issue with it there.

    -doy
  • Ricardo Signes at Nov 21, 2011 at 3:46 pm
    * Ricardo Signes [2011-11-10T18:37:05]
    https://rt.perl.org/rt3//Ticket/Display.html?id=80628

    This thread became quiet because 5.13 went into a holding pattern before 5.14.
    I would like, so help me, to bring it up again.
    Sorry for the delay in response since this thread quited down. Those of you
    who have worked with me on other code know that I am a notorious ponderer, and
    like to take a lot of time to stare at the wall and think about even the most
    trivial decisions.

    So, I have not been ignoring this thread, but thinking about it while riding
    the bus, eating chips, and ignoring other threads.

    __SUB__ belongs in the language. I leave the application of the commits to
    Father C. -- thanks for the work, Sprout, I look forward to using it.

    --
    rjbs
  • Aristotle Pagaltzis at Nov 21, 2011 at 4:32 pm

    * Ricardo Signes [2011-11-21 16:50]:
    Those of you who have worked with me on other code know that I am
    a notorious ponderer, and like to take a lot of time to stare at the
    wall and think about even the most trivial decisions.
    I am relieved. That is a great trait for a pumpking. :-)
  • Chris Prather at Nov 21, 2011 at 11:40 pm

    On Mon, Nov 21, 2011 at 11:32 AM, Aristotle Pagaltzis wrote:
    * Ricardo Signes [2011-11-21 16:50]:
    Those of you who have worked with me on other code know that I am
    a notorious ponderer, and like to take a lot of time to stare at the
    wall and think about even the most trivial decisions.
    I am relieved. That is a great trait for a pumpking. :-)
    But it's hell when you go out to dinner with him.

    -Chris
  • Aristotle Pagaltzis at Nov 22, 2011 at 1:18 am

    * Chris Prather [2011-11-22 00:45]:
    On Mon, Nov 21, 2011 at 11:32 AM, Aristotle Pagaltzis wrote:
    * Ricardo Signes [2011-11-21 16:50]:
    Those of you who have worked with me on other code know that I am
    a notorious ponderer, and like to take a lot of time to stare at
    the wall and think about even the most trivial decisions.
    I am relieved. That is a great trait for a pumpking. :-)
    But it's hell when you go out to dinner with him.
    Honestly? I would be fine with it then too. :-) Maybe I should make
    a note to go out for drinks with him if we ever meet.

Related Discussions

People

Translate

site design / logo © 2021 Grokbase