FAQ
Hello,

P.S. Please cc any replies to me as I'm not subscribed to p5p.

I would appreciate Perl 5.13.x+ having native support for octal numeric literals
having a 2-character prefix like already exists for binary and hex numeric
literals. It would take the form 0oNN, like the existing 0bNN and 0xNN. Perl 6
specifies all of these, as well as 0dNN, and I would like Perl 5 to have it too.

While I had thought I read recently in a delta that this was already
implemented, on further look that doesn't seem to be the case, but rather \oNN
in strings was added.

The perltodo with 5.13.6 still lists 0oNN support as an item. And I know it
doesn't work in 5.12.2.

I am willing to sponsor this update as an informal grant to a maximum of $100
(CAD, USD, AUD are all nearly at par these days), paid after the fact either to
whomever does it or paid to either TPF or EPO or similar nonprofit.

While that may not cover someone's time, I believe that this is a strongly
desired enough feature that there is impetus to do it anyway, and I'd like to
think it isn't too difficult.

The primary deliverable is that I can take a released Perl 5.13.x and use 0oNN
in it as a numeric literal same as that one can use 0NN now, but that presumably
a use of the latter would produce a warning citing to use the former instead.

My preferred payment/donation method is electronic/internet, denominated in the
recipient's currency.

Quality and thoroughness and exact semantics should be to the normal p5p
standards, including that there should be an added test for this.

Similarly, 0NN could probably become deprecated at the same time, for possible
removal in 5.15.x or later.

For bonus points, provide 0dNN also, for parity.

Thank you in advance.

-- Darren Duncan

Search Discussions

  • Darren Duncan at Nov 1, 2010 at 9:23 pm
    Actually, to clarify, I consider the 0dNN syntax quite important too, and so the
    offered grant of up to $100 is to add *both* 0oNN plus 0dNN syntaxes, so then
    the 4 [bodx] are supported, like Perl 6 does. A rationale for having 0d also is
    that users can then write literals with leading zeros in all 4 radixes and there
    would be no confusion of the meaning versus 0NN both now and after the possible
    removal of 0NN meaning octal later. And meanwhile any 0NN in code can then give
    a warning to suggest either 0o or 0d depending what is meant. -- Darren Duncan

    Darren Duncan wrote:
    Hello,

    P.S. Please cc any replies to me as I'm not subscribed to p5p.

    I would appreciate Perl 5.13.x+ having native support for octal numeric
    literals having a 2-character prefix like already exists for binary and
    hex numeric literals. It would take the form 0oNN, like the existing
    0bNN and 0xNN. Perl 6 specifies all of these, as well as 0dNN, and I
    would like Perl 5 to have it too.

    While I had thought I read recently in a delta that this was already
    implemented, on further look that doesn't seem to be the case, but
    rather \oNN in strings was added.

    The perltodo with 5.13.6 still lists 0oNN support as an item. And I
    know it doesn't work in 5.12.2.

    I am willing to sponsor this update as an informal grant to a maximum of
    $100 (CAD, USD, AUD are all nearly at par these days), paid after the
    fact either to whomever does it or paid to either TPF or EPO or similar
    nonprofit.

    While that may not cover someone's time, I believe that this is a
    strongly desired enough feature that there is impetus to do it anyway,
    and I'd like to think it isn't too difficult.

    The primary deliverable is that I can take a released Perl 5.13.x and
    use 0oNN in it as a numeric literal same as that one can use 0NN now,
    but that presumably a use of the latter would produce a warning citing
    to use the former instead.

    My preferred payment/donation method is electronic/internet, denominated
    in the recipient's currency.

    Quality and thoroughness and exact semantics should be to the normal p5p
    standards, including that there should be an added test for this.

    Similarly, 0NN could probably become deprecated at the same time, for
    possible removal in 5.15.x or later.

    For bonus points, provide 0dNN also, for parity.

    Thank you in advance.

    -- Darren Duncan
  • H.Merijn Brand at Nov 2, 2010 at 7:54 am

    On Mon, 01 Nov 2010 13:10:41 -0700, Darren Duncan wrote:

    Hello,

    P.S. Please cc any replies to me as I'm not subscribed to p5p.

    I would appreciate Perl 5.13.x+ having native support for octal numeric literals
    having a 2-character prefix like already exists for binary and hex numeric
    literals. It would take the form 0oNN, like the existing 0bNN and 0xNN. Perl 6
    specifies all of these, as well as 0dNN, and I would like Perl 5 to have it too.

    While I had thought I read recently in a delta that this was already
    implemented, on further look that doesn't seem to be the case, but rather \oNN
    in strings was added.

    The perltodo with 5.13.6 still lists 0oNN support as an item. And I know it
    doesn't work in 5.12.2.

    I am willing to sponsor this update as an informal grant to a maximum of $100
    (CAD, USD, AUD are all nearly at par these days), paid after the fact either to
    whomever does it or paid to either TPF or EPO or similar nonprofit.

    While that may not cover someone's time, I believe that this is a strongly
    desired enough feature that there is impetus to do it anyway, and I'd like to
    think it isn't too difficult.

    The primary deliverable is that I can take a released Perl 5.13.x and use 0oNN
    in it as a numeric literal same as that one can use 0NN now, but that presumably
    a use of the latter would produce a warning citing to use the former instead.
    I'm all in favor of implementing 0o and 0d, but I am strongly opposed
    to deprecating 0nnn as that would be to much of backward breakage as
    till now that was - except for calling the oct () function - the *only*
    way to denote octal numerals.
    My preferred payment/donation method is electronic/internet, denominated in the
    recipient's currency.

    Quality and thoroughness and exact semantics should be to the normal p5p
    standards, including that there should be an added test for this.

    Similarly, 0NN could probably become deprecated at the same time, for possible
    removal in 5.15.x or later.

    For bonus points, provide 0dNN also, for parity.

    Thank you in advance.

    -- Darren Duncan

    --
    H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
    using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00,
    11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.3 and AIX 5.2 and 5.3.
    http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
    http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
  • David Cantrell at Nov 2, 2010 at 11:30 am

    On Tue, Nov 02, 2010 at 08:54:15AM +0100, H.Merijn Brand wrote:

    I am strongly opposed
    to deprecating 0nnn as that would be to much of backward breakage as
    till now that was - except for calling the oct () function - the *only*
    way to denote octal numerals.
    Also because 0NN is *the* way of representing octals in a great many
    other languages and environments with which perl typically
    inter-operates, and which perl users are familiar with.

    --
    David Cantrell | top google result for "topless karaoke murders"

    You can't spell "slaughter" without "laughter"
  • Zefram at Nov 2, 2010 at 10:45 am

    Darren Duncan wrote:
    I would appreciate Perl 5.13.x+ having native support for octal numeric
    literals having a 2-character prefix like already exists for binary and
    hex numeric literals.
    We've discussed this previously. There is a problem with extending Perl
    numeric syntax, in that the sui generis lexing means that a lot of what
    looks like new syntax is actually already valid syntax. This particularly
    affects things like fractional hex, where "0x1.23" is already a valid
    expression. The approach we found most agreeable was that there should
    be a plugin mechanism to allow arbitrary numeric lexing, to be controlled
    by lexical pragmata. It's on my to-do list, but I've been concentrating
    on other things that I think are more important to get into 5.14.

    -zefram
  • Ævar Arnfjörð Bjarmason at Nov 2, 2010 at 11:56 am

    On Mon, Nov 1, 2010 at 20:10, Darren Duncan wrote:
    I would appreciate Perl 5.13.x+ having native support for octal numeric
    literals having a 2-character prefix like already exists for binary and hex
    numeric literals.  It would take the form 0oNN, like the existing 0bNN and
    0xNN.  Perl 6 specifies all of these, as well as 0dNN, and I would like Perl
    5 to have it too.

    While I had thought I read recently in a delta that this was already
    implemented, on further look that doesn't seem to be the case, but rather
    \oNN in strings was added.

    The perltodo with 5.13.6 still lists 0oNN support as an item.  And I know it
    doesn't work in 5.12.2.

    I am willing to sponsor this update as an informal grant to a maximum of
    $100 (CAD, USD, AUD are all nearly at par these days), paid after the fact
    either to whomever does it or paid to either TPF or EPO or similar
    nonprofit.

    While that may not cover someone's time, I believe that this is a strongly
    desired enough feature that there is impetus to do it anyway, and I'd like
    to think it isn't too difficult.

    The primary deliverable is that I can take a released Perl 5.13.x and use
    0oNN in it as a numeric literal same as that one can use 0NN now, but that
    presumably a use of the latter would produce a warning citing to use the
    former instead.

    My preferred payment/donation method is electronic/internet, denominated in
    the recipient's currency.

    Quality and thoroughness and exact semantics should be to the normal p5p
    standards, including that there should be an added test for this.

    Similarly, 0NN could probably become deprecated at the same time, for
    possible removal in 5.15.x or later.

    For bonus points, provide 0dNN also, for parity.
    Where is my money:

    http://github.com/avar/perl/compare/blead...octal-literal

    :)

    I did that back in January at the behest of someone (rjbs, rafl?), but
    didn't polish it up for submission.

    The hard part (I thought) was the "\o{060}" syntax. But it seems some
    code fairy helpfully did that.

    But literals are easy, and that goes for 0dXXX literals as well.

    Polishing it up, documenting it, testing it and having you owe me $100
    of beer at a YAPC doesn't sound too bad :)
  • Darren Duncan at Nov 2, 2010 at 6:59 pm

    Zefram wrote:
    We've discussed this previously. There is a problem with extending Perl
    numeric syntax, in that the sui generis lexing means that a lot of what
    looks like new syntax is actually already valid syntax. This particularly
    affects things like fractional hex, where "0x1.23" is already a valid
    expression. The approach we found most agreeable was that there should
    be a plugin mechanism to allow arbitrary numeric lexing, to be controlled
    by lexical pragmata. It's on my to-do list, but I've been concentrating
    on other things that I think are more important to get into 5.14.
    To clarify up front, I'm just asking for parity of support of numeric literals
    across all 4 of [0b,0o,0d,0x]; in other words, what 0bN,0xN,0N already support,
    which is just integers.

    While generic numeric syntax would be nice, 0bN,0xN don't currently support that
    in Perl 5 and so that isn't required for the bounty.

    Looking at it that way, I would expect adding 0o,0d for just integers should be
    trivial. It is mainly working with the "." that adds the complexity.

    H.Merijn Brand wrote:
    I'm all in favor of implementing 0o and 0d, but I am strongly opposed
    to deprecating 0nnn as that would be to much of backward breakage as
    till now that was - except for calling the oct () function - the *only*
    way to denote octal numerals.
    Leaving 0nnn un-deprecated isn't a problem for me; the syntax addition was
    mainly what I wanted. And I recognize that 0nnn is the more common older syntax
    in several other languages.

    That said, I think that any uses of 0nnn should generate a warning, at least
    when the code already declares that it requires Perl 5.13+ somehow, *because* of
    the easy confusion with base 10; if the warning only occurs in this more
    specific situation of requiring 5.13+ then it is possible for code to be
    warnings free in both older and newer Perls without avoiding octal.

    On the other hand, 0nnn warnings could just be left to Perl::Critic. Your call.

    At the very least, the Perl documentation should be updated to say that 0oNN is
    recommended syntax when you know the code would only run in Perl 5.13.+, and 0NN
    just for backwards compatible code.

    Ævar Arnfjörð Bjarmason wrote:
    Where is my money:

    http://github.com/avar/perl/compare/blead...octal-literal

    :)

    I did that back in January at the behest of someone (rjbs, rafl?), but
    didn't polish it up for submission.

    The hard part (I thought) was the "\o{060}" syntax. But it seems some
    code fairy helpfully did that.

    But literals are easy, and that goes for 0dXXX literals as well.

    Polishing it up, documenting it, testing it and having you owe me $100
    of beer at a YAPC doesn't sound too bad :)
    Thank you; it sounds like you're on the way. So now just get that into a
    shipping Perl 5.13.x/5.14.0 and then I'll owe you. Specifically 0o plus 0d
    integer support with the polish and tests into shipping. Anything beyond that
    and I'll also owe you further gratitude.

    -- Darren Duncan
  • Tom Christiansen at Nov 2, 2010 at 7:27 pm
    That said, I think that any uses of 0nnn should generate a warning,
    Lord, no!

    --tom
  • Alberto Simões at Nov 2, 2010 at 7:55 pm

    On 02/11/2010 19:27, Tom Christiansen wrote:
    That said, I think that any uses of 0nnn should generate a warning,
    Lord, no!
    Plz, no!
    --
    Alberto Simões
  • Darren Duncan at Nov 2, 2010 at 8:14 pm

    Tom Christiansen wrote:
    That said, I think that any uses of 0nnn should generate a warning,
    Lord, no!
    Actually, you're right.

    I formally retract any request for the existing/older octal syntax to generate a
    warning under any circumstances.

    Instead, I think that any matters concerning 0nnn should be kept in the
    documentation and Perl::Critic, and leave it at that. Surely this is agreeable?

    Darren Duncan wrote:
    At the very least, the Perl documentation should be updated to say that
    0oNN is recommended syntax when you know the code would only run in Perl
    5.13.+, and 0NN just for backwards compatible code.
    Actually, this makes me think of something important.

    Assuming that the addition of 0o and 0d for integer literals is indeed trivial
    and fully backwards compatible, I think that this would be a prime candidate for
    back-porting.

    That way, the supposed best practice of using the newer octal syntax is then
    also compatible with a wider range of Perls, and people don't have to hold back
    on using it for the sake of backwards compatibility.

    So, I amend my request such that not only are 0o plus 0d integers added to blead
    in time for 5.14.0 to ship with them, but that these are also back-ported to the
    living maint branches. So at the very least, 5.12.3 (say) would include them
    too, which might likely be the first stable appearance. And 5.10.2 or 5.8.10 if
    such come to exist.

    I would imagine that this change should back-port cleanly.

    Does anyone object to this making it into the next 5.12.x release?

    -- Darren Duncan

    P.S. I also want to clarify that I'm assuming that all 4 of "0[bodx]NN" would
    support arbitrary leading zeros between the [bodx] and the NN.
  • Zefram at Nov 2, 2010 at 8:31 pm

    Darren Duncan wrote:
    Assuming that the addition of 0o and 0d for integer literals is indeed
    trivial and fully backwards compatible, I think that this would be a
    prime candidate for back-porting.
    No chance. We don't put new features into maint branches generally,
    and this is a feature that changes syntax.

    -zefram
  • Darren Duncan at Nov 2, 2010 at 9:44 pm

    Zefram wrote:
    Darren Duncan wrote:
    Assuming that the addition of 0o and 0d for integer literals is indeed
    trivial and fully backwards compatible, I think that this would be a
    prime candidate for back-porting.
    No chance. We don't put new features into maint branches generally,
    and this is a feature that changes syntax.
    Is Unicode 6.0 going into 5.12.x? I don't see that what I asked for is
    significantly different in effect. It shouldn't affect anyone that doesn't use
    it. I'm more inclined to hope you would make an exception here. Would the
    addition not provide any benefit to code maintenance or Perl training? At
    seemingly negligible cost?

    The only material problem that I might see happening here is if users get
    confused as to which versions of Perl they can use the new syntax with. Eg,
    5.12.3+ work and 5.12.2- don't, ignoring developer versions. But is this really
    a problem?

    -- Darren Duncan
  • Ricardo Signes at Nov 2, 2010 at 9:55 pm
    * Darren Duncan [2010-11-02T17:44:01]
    Is Unicode 6.0 going into 5.12.x?
    No.

    Subversions are for critical bugfixes and security issues.

    --
    rjbs
  • Darren Duncan at Nov 2, 2010 at 9:56 pm
    Actually, never mind. Just getting into 5.14.0 is good enough and I won't argue
    further for this back-porting. But if other people can make a case for
    back-porting this, that's fine with me. -- Darren Duncan

    Darren Duncan wrote:
    Zefram wrote:
    Darren Duncan wrote:
    Assuming that the addition of 0o and 0d for integer literals is
    indeed trivial and fully backwards compatible, I think that this
    would be a prime candidate for back-porting.
    No chance. We don't put new features into maint branches generally,
    and this is a feature that changes syntax.
    Is Unicode 6.0 going into 5.12.x? I don't see that what I asked for is
    significantly different in effect. It shouldn't affect anyone that
    doesn't use it. I'm more inclined to hope you would make an exception
    here. Would the addition not provide any benefit to code maintenance or
    Perl training? At seemingly negligible cost?

    The only material problem that I might see happening here is if users
    get confused as to which versions of Perl they can use the new syntax
    with. Eg, 5.12.3+ work and 5.12.2- don't, ignoring developer versions.
    But is this really a problem?
  • Nicholas Clark at Nov 3, 2010 at 8:25 am

    On Tue, Nov 02, 2010 at 02:44:01PM -0700, Darren Duncan wrote:
    Zefram wrote:
    Darren Duncan wrote:
    Assuming that the addition of 0o and 0d for integer literals is indeed
    trivial and fully backwards compatible, I think that this would be a
    prime candidate for back-porting.
    No chance. We don't put new features into maint branches generally,
    and this is a feature that changes syntax.
    Is Unicode 6.0 going into 5.12.x? I don't see that what I asked for is No.
    significantly different in effect. It shouldn't affect anyone that doesn't
    use it. I'm more inclined to hope you would make an exception here. Would
    the addition not provide any benefit to code maintenance or Perl training?
    At seemingly negligible cost?

    The only material problem that I might see happening here is if users get
    confused as to which versions of Perl they can use the new syntax with.
    Eg, 5.12.3+ work and 5.12.2- don't, ignoring developer versions. But is
    this really a problem?
    Yes.

    It means that you can't install latest 5.even.x, write code, and expect it to
    work on all 5.even.

    The analogous situation I found myself in 10 years ago was having to backport
    the 5.004_05 platform build fixes to 5.004_04, because I needed to write code
    that would run on 5.004_04. 5.004_05 *added* the statement modifiers,
    backported from 5.005. Which is very useful, I'm sure, unless you want to be
    sure that your code doesn't contain any.

    So yes, it's a problem.

    Nicholas Clark
  • David Golden at Nov 3, 2010 at 11:47 am

    On Tue, Nov 2, 2010 at 4:13 PM, Darren Duncan wrote:
    Assuming that the addition of 0o and 0d for integer literals is indeed
    trivial and fully backwards compatible, I think that this would be a prime
    candidate for back-porting.

    Does anyone object to this making it into the next 5.12.x release?
    Others have jumped on this already, but I wanted to give a link to the
    official policy regarding what goes into maintenance branches:

    http://perldoc.perl.org/perlpolicy.html#MAINTENANCE-BRANCHES

    -- David
  • Aristotle Pagaltzis at Nov 11, 2010 at 1:24 am

    * Darren Duncan [2010-11-02 21:15]:
    So, I amend my request such that not only are 0o plus 0d
    integers added to blead in time for 5.14.0 to ship with them,
    but that these are also back-ported to the living maint
    branches. So at the very least, 5.12.3 (say) would include
    them too, which might likely be the first stable appearance.
    And 5.10.2 or 5.8.10 if such come to exist.
    What’s the point?

    There was temptation to put features into point releases until
    recently because major releases took so unbearably long to
    escape.

    The development cycle has since changed such that major releases
    are happening frequently now and from here on out. New features
    do not have to wait around for a long time before they get into
    a release available to users. Point releases are there to pool the
    most important fixes in the meantime, and hopefully will be few.

    Both 5.10.2 and 5.8.10, FWIW, are almost certain to never happen.

    So it need be no concern for you if a feature never makes it into
    point releases of obsolete major releases. That will not delay it
    from getting into end users’ hands.

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Ævar Arnfjörð Bjarmason at Nov 2, 2010 at 10:49 pm

    On Tue, Nov 2, 2010 at 18:57, Darren Duncan wrote:
    Ævar Arnfjörð Bjarmason wrote:
    Where is my money:

    http://github.com/avar/perl/compare/blead...octal-literal

    :)

    I did that back in January at the behest of someone (rjbs, rafl?), but
    didn't polish it up for submission.

    The hard part (I thought) was the "\o{060}" syntax. But it seems some
    code fairy helpfully did that.

    But literals are easy, and that goes for 0dXXX literals as well.

    Polishing it up, documenting it, testing it and having you owe me $100
    of beer at a YAPC doesn't sound too bad :)
    Thank you; it sounds like you're on the way.  So now just get that into a
    shipping Perl 5.13.x/5.14.0 and then I'll owe you.  Specifically 0o plus 0d
    integer support with the polish and tests into shipping.  Anything beyond
    that and I'll also owe you further gratitude.
    Cool. I'll see what I can do about that. I should have some time soon
    to polish that up.
  • Abigail at Nov 3, 2010 at 11:50 am

    On Tue, Nov 02, 2010 at 11:57:11AM -0700, Darren Duncan wrote:
    That said, I think that any uses of 0nnn should generate a warning, at
    least when the code already declares that it requires Perl 5.13+ somehow,
    *because* of the easy confusion with base 10; if the warning only occurs
    in this more specific situation of requiring 5.13+ then it is possible
    for code to be warnings free in both older and newer Perls without
    avoiding octal.

    I strongly disagree with the sentiment. I do not think it's right to
    start warning for a construct that has worked well in the 20+ years of
    Perls existance, (40+ years if you count other languages), just because
    someone is aggressively promoting his favourite alternative syntax.



    Abigail

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl5-porters @
categoriesperl
postedNov 1, '10 at 8:10p
activeNov 11, '10 at 1:24a
posts19
users12
websiteperl.org

People

Translate

site design / logo © 2022 Grokbase