Re: continuation enhanced arcs
jon...@bright.net
> Very embarrassing delurk just to say...
>
> In my opinion, one of the best things about Perl6 was that you'd
> be able to use a "my int $i" (as opposed to "my Int $i") and get
> an extremely speedy, tiny little I register variable with no
> overhead or PMC bulk.
Which, ordinarily, isn't what you should want.
> I'd use them for almost all my int-y variables where I didn't
> need any additional cruft [...]
The prevalence of this sort of thinking is precisely why I cringed
when I read that in the Apocalypse, and why I am nearly certain
that inclusion of these types in Perl6 is a Very Bad Idea. People
will use them all the time without thinking, because "it'll be faster".
There are two very strong arguments against this:
1. It's not "faster" enough to make any worthwhile difference in
the overwhelming majority of cases. On a modern system with
a decent-sized L2 cache (and bear in mind that by the time
this code enters production, what we right now consider a
modern system will be old and cheap on Ebay), the performance
impact of double referencing is next to nothing.
2. There's a reason high-level data structures were developed:
they obviate entire classes of subtle, hard-to-debug bugs.
(Not as subtle or hard-to-find as pointer-related bugs, but
nevertheless, subtle and hard to find.) Throwing out those
advantages for a few picoseconds of potential optimization
is, in the vast majority of cases, a very poor trade.
Yes, there are a few cases where using these variable types
would be appropriate, in carefully considered situations, but
people who are thinking, "Wow, this is the greatest thing since
sliced bread, I'm going to use this for most my integer
variables" have failed to learn the hard lessons the software
industry has had to learn over the last thirty years.
To illustrate, I'll go back and more closely examine your
statement above:
> I'd use them for almost all my int-y variables where I didn't
> need any additional cruft [...]
That additional "cruft", as you put it, is in fact a safety net.
The question you should be asking yourself is, how do you KNOW
whether you're going to need the "cruft" or not, in any given
instance? Let's consider as our given instance the precise
example you cite:
> like as an index in a for loop (who needs all the cruft there?
> You just want a number that goes up one every time!).
For the moment, let's ignore the fact that in Perl6 the C-style for
loop is (thank goodness) going away, and for is merely a synonym for
foreach. Someone will certainly implement a module that provides a
C-style for loop (implemented in terms of while, I suppose), and so
we'll assume you're using that:
my int $x;
c_style_for ($x = 0; $x < $y; ++$x) {
do_stuff();
}
The question is, how do you know this isn't buggy? How do you
know that $x won't overflow? How do you know that $x won't overflow
only in certain special circumstances -- perhaps only if the size of
the program's input is abnormally large, or perhaps only late at
night or late in the month, or perhaps only on certain architectures,
or in other special circumstances you'll neglect to test? You don't.
In many cases you *can't* know that, and even in the cases where you
can, it will generally involve more desk-checking and precise
calculation of pathological cases than most programmers want to do.
In rare cases the performance of a particular bit of code is so
critical (perhaps because it is embedded in a triple-nested loop)
that it's worth working out all those details and calculating exactly
what the maximum possible value is and thus what size variable you
need. In normal situations, however, it's not worth it, and you
won't do it. A high-level data type saves you from needing to
calculate that for every variable (and, indeed, in many cases it's
not even POSSIBLE to calculate the max possible value), because it
will autopromote if necessary rather than overflow. At least, the
Apocalypse hinted that if it doesn't do that by default, there will
be an easily invoked pragma to make it do that. Personally I'd
prefer that all variables do that all the time, and if the programmer
every *actually* wants overflow semantics for some hyperunusual
reason (e.g., to emulate legacy computer-system behavior), that can
be easily implemented as a special class of OverFlowingInt object
that checks after each operation to see if its value has exceeded
some maximum and if so throws an exception or does some modular
arithmetic or something, depending on which type of overflow you
prefer.
> Nearly all modules could make great use of them for speedy
> internal variables, too.
I certainly hope not. Mindlessly using lowlevel types without regard
for the consequences is NOT the direction Perl programmers should want
to go.