Damian Conway wrote:
Surely this is not a common-enough requirement to warrant a special

At 80-columns, you can represent integers up to
Surely that's enough for the vast majority of users, isn't it?

Well, 80 columns was an example, albeit the most common, but the principle idea was to support writing code that fit into very narrow spaces (such as may result from having the 80-col constraint plus a whole bunch of code indent levels) while being able to keep the code easily readable and nicely formatted.

I also figured that this would be a fairly simple thing to do.

Part of the idea was that one could also wrap any long identifiers as well to fit in a narrow space.

Now, granted that expressing every thing which might become long as a string literal could probably work, it seemed somewhat inelegant, though maybe the problem is uncommon enough that this is an acceptable sacrifice.

And if you *do* need anything bigger (perhaps to represent the burgeoning
U.S. national debt) then there's always some variation on:

    my $debt = +(
      ~ 567890123456789012345678901234567890123456789012345678
      ~ 901234567890123456789012345678901

or even:

    my $debt = +(
      ~ 567_890_123_456_789_012_345_678_901_234_567_890_123_456_789_012_345_678
      ~ 901_234_567_890_123_456_789_012_345_678_901

if you like to group your thousands for better readability.

With adequate constant folding, both of those are still compile-time constants.

That sounds half-reasonable, though it would seem to me that you'd have to quote each piece of the number to make it work right if you were using anything other than base 10. And we're assuming that +(...) isn't producing a Num instead of an Int or Rat as the case may be, as if the rules for +(...) were the same as the parser's rules for what kind of number it makes.

So if we leave things as is, then hopefully the examples you raised will be commonly supported as compile-time constants in Perl 6 implementations.

-- Darren Duncan

Reply via email to