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 = +(
my $debt = +(
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