| Dan Nagle 2007-08-31, 9:03 am |
| Hello,
I was thinking about responding to this by posting the module
which provided all the functionality of BITS, but I can see
I won't have the time (school's started). And there's no
f08 compilers to check it with anyway.
James Giles wrote:
> Dan Nagle wrote:
> ...
>
> When I call you a liar you'll know it. I don't mince words.
But you do get things wrong. And you got this wrong.
<snip>
I agree that the functions weren't the only functionality
of BITS. That's why the functions weren't the only items
added in N1695. And don't forget the other functionality
of f03 and f08 not in f95 which may be combined to provide
the full functionality of BITS.
> "BITS functionality" would be things BITS did that nothing
> else in the language does (or does as well). Bit-resolution
> KINDs, are an example.
The functionality is something nothing else in the language
does. If there's another way to do it that's less convenient,
the loss is a loss of convenience, not functionality. Why
do you suppose I distinguished the two? (And I checked
with a dictionary to ensure my usage is reasonable.)
Bit size as a function of kinds may be done by the application
programmer via a parameterized derived type. Perhaps this is
one situation where experience with f03 would be helpful.
Note that the programmer has more control over the BITS type
when it's done by the programmer as a PDT. Specifically,
whether the bit size is a kind or length type parameter
(many of the proponents of BITS wanted the size to be length type),
and the manner of packing (fast and word-oriented, or
slow and space-saving). Packing was *not* specified by BITS
as proposed.
As an aside, note further that the kind-type parameter means
that each distinct length must have its own procedures, that
may be inconvenient when there are more than a few sizes
in one program.
> Whether you call it "functionality"
> or not, most of the really significant features of the BITS data
> type have been eliminated.
No, that functionality is simply something the applications
programmer must code explicitly. That may be inconvenient.
> And, as I've said, I didn't like BITS.
> I think all of those features would be better implemented
> differently.
I agree. BITS was a compromise nobody really liked.
But it was what was agreed, and that's why it died.
> But I think some of them had sufficient merit
> that it's not valid to claim that nothing was lost when the
> proposal was abandoned.
I _never_ claimed "nothing" was lost.
I do claim that >>> no functionality <<< was lost.
I repeat that claim now. Some functionality is roll-yer-own
that would have been more conveniently available with BITS.
But (outline of proof-by-construction)
use, implicit :: iso_fortran_env, only: numeric_storage_size
! a Fortran 2003 parameterized derived type
! with a kind type parameter
type :: bits_t( bit_len)
integer, kind :: bit_len
! a packed bits type
! unpacked is easier
integer, dimension( bit_len / numeric_storage_size + 1) :: bits
contains
! one for each kind type bit_len
! this is easier if bit_len is length type
<name operators, assignments and conversions here,
or below the module contains>
end type bits_t
! distinct kinds of bits variables
type( bits_t( 7)) :: bits7
type( bits_t( 42)) :: bits42
type( bits_t( 86)) :: bits86
type( bits_t( 99)) :: bits99
provides the bit-wise kind resolution.
And the programmer has control over all the details
left unspecified by BITS as proposed.
The vendors claimed that the cost of implementing BITS
would not be worth the benefit. That claim is supported
by the observation that no vendor _actually had_ anything like BITS
in their compiler. Thus, one may conclude there was low demand.
(The closest is Sun, who have unsigned integers.)
I accept that PDTs may be the last feature of f03 generally
implemented; the vendors are in universal agreement that
it is the hardest feature in f03 to implement. But it is
fully part of the language.
WG5 and J3 went through the BITS proposal very carefully
to preserve the full functionality in f08. What _functionality_
is missing?
--
Dan Nagle
Purple Sage Computing Solutions, Inc.
|